1. Introduction

ProoveMe: Software Requirements Document (SRD)

1.​Full Stack:

1.1​Product summary

ProoveMe is an AI-first professional platform. Professionals show evidence of their real-world contributions, achievements

and impact ("Impacts"). Employers discover talent through these evidence-led profiles instead of job titles and CV keywords.

The platform launches in Nigeria first, with international employer access, and must be ready for international expansion.

(Brief, E1 )

E3-A2

E3-A5

Brief §9

5.​Brand

Requirement

Source

Message: "Your experience tells. Your impact proves." Promise: "Make your impact visible."

Technical Specification

This SRD is based on the ProoveMe Quotation Brief v1.1 and ProoveMe's emails to date. It is a draft and not a statement of work.

AI Approach:

.

1. Purpose and scope

1.1 Background

ProoveMe is a Nigeria-first professional proof and talent platform, built to be ready for international expansion. It helps

professionals present credible examples of the work they have done, and helps organisations find relevant experience

beyond job titles and CV keywords. The brand message is: Your experience tells. Your impact proves. The brand promise is:

Make your impact visible.

The platform is a complete new build. No existing code, database, authentication, backend or design assets are assumed

reusable. It must be clear, fast, trustworthy, mobile-first and accessible to users at different career stages, including

graduates, early-career professionals, career changers and experienced professionals of all ages.

1.2 Source documents

This SOW is based on the following, all dated October to November 2026:

●​ ProoveMe External Developer Enquiry and Indicative Quotation Brief, version 1.1 (2 November 2026), including

the addendum on growth, referrals and platform safeguards.

●​ The founder's enquiry message to the supplier.

●​ The supplier's AI feasibility assessment and AI clarification queries.

●​ The client's reply to the feasibility assessment, which answered most AI questions.

●​ The FS team's clarification questions, Part A (platform, scope and delivery), and the AI team's Part B (AI

functionality).

2. Requirements traceability

2.1 Brief section 5A: AI-led Impact discovery, drafting and ongoing management

2. System Overview

2.​Scope summary

Module

State at production launch

Source

Marketing website

Live

Brief §4, E1

Professional accounts, onboarding, Impacts, evidence,

profiles, sharing

4.​Platform structure

The platform has two main applications and one admin panel, sharing one backend and database. (Brief §9)

2.​ Marketing website: the public pages.

3.​ Main web application: the professional, employer and partner areas, plus the marketplace and messaging modules

(disabled in production).

4.​ Admin panel: ProoveMe administration.

Clear separation of public pages, professional areas, employer areas, administration and marketplace

modules

Brief §9

Requirement

Source

Cover these screen groups: Public (homepage, audience landing page, FAQ/trust),

Professional (onboarding, Impact editor, dashboard, profile, evidence controls), Employer

(registration, search, results, profile detail, shortlist), Partner (foundation screens),

Marketplace (discovery, role detail, application, employer posting, applicant review). The full

screen list is in section 1 6.1 .

Brief §8, E3-A4

DES-

16.​Build reference

This section turns the requirements above into the building blocks of a plan: the screens, the Impact status rules, the data

records and the milestones. It adds no new scope. Every item refers back to requirement IDs.

16.3​Data records

These are the main records the platform stores. Each record is defined once, and features refer to it.

Record

7.2 Logical components

Component

Responsibility

Ingestion service

Receives a platform-approved file, extracts and structures text,

checks quality

7.2 Logical components

Component

Responsibility

Impact engine

Candidate detection, drafting, follow-up question generation,

duplicate detection

Verification service

Checks drafts against source and user answers, including

programmatic number and entity checks

Suggestion service

Handles user-triggered new and revised Impact proposals and

the review queue

Evidence analysis service

Access-controlled analysis of uploaded evidence

Search support service

Indexing of consented content, retrieval, match explanations

Provider gateway

Provider abstraction, configuration, region and retention

settings, usage limits

Evaluation harness

Test sets, regression runs, quality reports

Monitoring

The product is a website named “super-website”.

3. Functional Requirements

PLN-

06

Each screen in section 1 6.1 has its own frontend task, covering every screen state in ACC-04.

Brief §5,

§5A

Live

Brief §5A,

E2, E3-B

Third-party verification

E3-A3

Brief §5,

§5A

Brief §5A,

E2, E3-B

Organisation onboarding and verification

Live

AI integration: screens, workflows and backend integration

for the AI features (the AI itself is in the separate AI

document)

Brief §6,

Add. B

Employer discovery, shortlists and contact requests

Partner and cohort foundation

Referrals, analytics and experiment readiness

Brief Add. A

Administration panel

Brief §1

Opportunity marketplace

Built and tested, disabled in

production

Marketplace messaging

Monetisation (plans, subscriptions, entitlements)

4.1​How the frontend, backend and AI connect

The frontend never talks to the AI directly. Every AI request goes through the ProoveMe backend, which checks the user,

permissions and consent before calling the AI, and saves the result as a draft. (E2, E3-B7, E3-AI, A26)

API calls

1.​The frontend sends the request to the backend, for example "analyse my CV".

2.​The backend checks the user's identity, permissions, AI consent and usage limits.

3.​The backend sends only the data needed to the AI service, through one integration layer.

4.​The AI service returns its result to the backend.

5.​The backend validates the result, saves it with "AI draft" status, and updates the job status.

6.​The frontend shows the progress, then the draft for the user to approve, edit or reject.

The detailed requirements are in section 6.17.

Brief (Brand

direction)

6.​Functional requirements

6.1​Marketing website (MKT)

ID

Requirement

Source

MKT-

01

Responsive homepage that explains ProoveMe within the first screen, using a real product

Brief §4

preview instead of stock imagery

Source

MKT-

01

Brief §4

02

Clear routes for Professionals, Employers/Recruiters and Partners, with one primary sign-up

call to action

Source

MKT-

01

Brief §4

03

Audience landing page for each audience

Brief §8

preview instead of stock imagery

04

Pages: How it works, sample anonymised Impact, privacy and trust, FAQ, contact and legal

pages

Brief §4

MKT-

05

Contact page with a form that sends enquiries to a ProoveMe email address

Brief §4,

A23

MKT-

Consent banner for analytics and non-essential cookies

6.2​Accounts and authentication (AUTH)

ID

Requirement

Source

AUTH-01

Email registration with email verification and minimal initial fields

Brief §5, E3-A1 1

6.2​Accounts and authentication (AUTH)

ID

Requirement

Source

AUTH-02

Google sign-in

E3-A1 1

AUTH-03

Secure password recovery

Brief §9

AUTH-04

Rate limiting and bot controls on registration, sign-in and recovery

Brief §9, Add. B

AUTH-05

Separate permissions for professional, organisation, partner and admin accounts

E2

AUTH-06

Multi-factor authentication for ProoveMe admin accounts

Brief §9, A1 4

6.3​Professional onboarding and Impacts (PRO)

ID

Requirement

Source

PRO-

01

Onboarding offers four start paths: PRO-01 a to PRO-01 d. Each path is a separate flow

with its own screens.

Brief §5,

E3-B4

PRO-

01 a

Start path 1 , CV upload: the professional uploads a CV, which is analysed in the

background (see PRO-02, INT-07)

Brief §5,

E3-B4

PRO-

01 b

Start path 2, free-text entry: the professional describes their experience in their own

words, which is analysed in the background

Brief §5,

E3-B4

PRO-

01 c

Start path 3, guided questions: the professional answers a set of questions about their

experience, one step at a time. Whether the answers are sent to the AI is TBC (A33).

E3-B4, A33

01 d

Brief §5,

E3-B4

PRO-

01 c

Start path 4, manual Impact creation: the professional creates Impacts without AI (see

PRO-05)

01 e

Onboarding progress is saved on every path, so the professional can leave and continue

later

Brief §5,

E3-B4

PRO-

02

CV upload supports PDF and Word, plus scanned and photographed CVs where

technically feasible. File-size and page limits to be recommended in the proposal.

E3-A1 2

PRO-

03

Supports employment, education, volunteering, freelance, informal and community

experience

E2, E3-B4

PRO-

04

Impact records follow the structure Situation → Decision → Action → Outcome → Evidence

Brief §5A

PRO-

05

Manual Impact creation and editing with guided prompts, for users who do not use AI

Brief §5, E2

06

Brief §5A

PRO-

05

Each AI-proposed Impact is approved, edited or rejected individually. Nothing is published

automatically.

07

Brief §5A

PRO-

07

Each Impact stores and displays its status separately: AI draft, user-approved,

evidence-backed or independently verified

PRO-

08

Approved Impacts can be saved, published and updated from the dashboard

Brief §5A

PRO-

09

Version history: when a professional approves a change to a published Impact, the

previous version stays auditable

E3-B2

PRO-

1 0

A material change to an Impact triggers re-review of the affected evidence or verification

status. Unrelated verified claims keep their status.

E3-B2, A5

1 1

Follow-up questions can be skipped, saved and returned to later

E3-AI

PRO-

1 2

Brief §5

1 3

Brief §5A, E2

1 4

Dashboard shows Impacts, evidence, profile visibility and pending actions (AI suggestions,

verification responses, contact requests)

When the professional adds new information or asks for suggestions, the AI suggests new

or updated Impacts. No change is applied without approval.

Profile headline and summary, with optional AI assistance subject to approval

PRO-

1 5

Location fields with Nigerian states and cities. Optional phone number with +234 support.

Brief §2

6.4​Evidence (EVD)

ID

Requirement

Source

EVD-

01

Professionals can attach files or links to an Impact

6.4​Evidence (EVD)

ID

Requirement

Source

Brief §5

EVD-

02

Supported evidence types: certificates, letters, reports and relevant images, with file

type and size validation

E3-B1

EVD-

03

All uploaded files are malware-scanned before they become available

Brief §9, E2

EVD-

04

Evidence is private by default. The professional sets the visibility of each item.

Brief §5, A6

EVD-

05

Restricted evidence is shared through permissioned links with expiry, revocation and an

audit trail

Brief Add. B

06

Public previews never expose source files. Direct file URLs are never exposed.

Brief Add. B,

Add. C

EVD-

07

E3-B1

08

E2

6.5​Profile, privacy and sharing (PRF)

ID

Requirement

Source

Private evidence and AI-generated evidence analysis never become visible to employers

automatically

PRF-

01

Professionals can preview, edit and publish a profile with selected Impacts

Brief §5

PRF-

02

Stable, user-controlled profile URL. Only content the professional has published is public.

Brief §5,

Add. A

PRF-

03

Visibility settings per profile and per Impact: private, verified employers only, or public

Brief Add. A,

A6

PRF-

04

Professionals choose whether they appear in employer search

Brief §1

PRF-

05

Profiles and individual Impacts can be shared through Open Graph previews, the standard

share action (WhatsApp, LinkedIn), QR code and copy link

Brief Add. A

PRF-

06

Contact details are private by default and shared only with the professional's explicit

permission or chosen public visibility

Brief Add. B

PRF-

07

Search engines index a public profile only if the professional opts in

Brief §1

0, A6

PRF-

08

Professionals can export their own data

Brief Add. B,

A22

PRF-

09

Professionals can delete their account. Data is deleted in line with the documented retention

policy.

E2, E3-B7

PRF-

1 0

Users can report a public profile, or a profile seen in employer search, for admin review (see

ADM-05)

A34

6.6​Third-party verification (VER)

ID

Requirement

Source

VER-

01

A professional can invite colleagues, managers or other appropriate people to confirm a

specific contribution or outcome

E3-A3, Brief

Add. A

6.6​Third-party verification (VER)

ID

Requirement

Source

VER-

02

Invitations are sent by email or link, with expiry and abuse limits

Brief Add. A

VER-

03

The verifier sees only the claim they have been asked to confirm

A4

VER-

04

Verifier identity check: email confirmation, plus the verifier's name, role and relationship to

the professional. A work-domain match is recorded. Mismatches are flagged for admin

review.

E3-A3, A3

VER-

05

The verifier can confirm, decline or add a comment

E3-A3, A3

VER-

06

Verification is linked to an individual claim. "Independently verified" status is given only

through this process and never by AI.

E3-A3, E3-

B5

VER-

07

An audit record is kept of who verified what and when, along with the identity check result

E3-A3

VER-

08

Admins review flagged verifications and can uphold or remove them

E3-A3

VER-

09

A material change to a verified claim triggers re-review (see PRO-1 0)

E3-B2

1 0

AI may help draft invitations and summarise responses (see 6.1 7)

E3-A3, E3-

B5

6.7​Organisation onboarding and verification (ORG)

ID

Requirement

Source

ORG-

01

Employer entry page that explains the proposition and lets an organisation request an

account

Brief §6

6.7​Organisation onboarding and verification (ORG)

ID

Requirement

Source

ORG-

02

Onboarding captures work identity (work email) and organisation details (name, website,

country and registration number)

Brief §6

ORG-

03

Work email verification. Free email domains are not accepted for organisation accounts.

Brief §6, A2

04

Brief §6

ORG-

03

Brief §6, A2

04

Admin approval is required before an organisation can access restricted profiles or contact

professionals

Brief §6,

Add. B

05

ORG-

06

Organisation admins can invite team members. Organisation roles: admin and member.

Brief Add. A

ORG-

08

Admins can suspend an organisation or revoke its verification

Brief §1

6.8​Employer discovery (EMP)

ID

Requirement

Source

EMP-

01

Search by experience, capabilities, professional outcomes and location

Brief §6

EMP-

02

Structured filters and keyword search

E3-B3

EMP-

03

Natural-language or semantic search where practical. The full-stack build provides the

search screens and search index. The AI service provides the text processing (A27).

E3-B3

04

Each result explains why it matched, based on experience, capabilities and approved

Impacts

E2, E3-B3

EMP-

05

Brief §6, Add.

B, E3-B3

06

Ranking is based on relevance, not popularity. No suitability scores, no "best" labels and

no automated rejection.

Brief §6, Add.

Results include only approved content that the professional has made available to

employers, and respect privacy and evidence permissions

E2

EMP-

07

Date of birth, marital status and state of origin do not influence matching and are not

available as filters

E3-AI

EMP-

08

Candidate view shows the permitted profile information and evidence status, with

evidence context and uncertainty

Brief §6, Add.

B

EMP-

09

Shortlists organised by recruitment project

Brief §6

EMP-

1 0

Saved searches

Brief §6

EMP-

1 1

Employer workspace showing saved searches, shortlists and permitted activity

1 2

Only verified organisations can search and view restricted profiles

Brief Add. B

EMP-

1 3

Anti-enumeration controls, rate limits and limits on bulk export

1 4

Profile views by organisations are logged

Brief §9

6.9​Contact requests (CON)

ID

Requirement

Source

CON-

01

A verified organisation can send a contact request to a professional, with context

Brief §6, Add.

B

Brief §9

6.9​Contact requests (CON)

ID

Requirement

Source

CON-

01

02

The professional accepts or declines. On acceptance, the contact details they choose

are shared.

Brief Add. B,

A7

CON-

03

Professionals can report spam and block organisations

Brief Add. B

CON-

04

Admin investigation tools for reported contact requests

Brief Add. B

CON-

05

Rate limits on contact requests

Brief Add. B

CON-

06

Permissions are enforced in the API so organisations cannot bypass them

Brief Add. B

ID

Requirement

Source

MKP-

01

Opportunities can be created by verified employers, authorised recruiters and approved

partners

E3-A6

ID

Requirement

Source

MKP-

02

Opportunity types: permanent, contract, internship, project and advisory

Brief §7

MKP-

03

Opportunity details include region, type, work arrangement, eligibility and expiry

Brief §7

MKP-

04

Organisations create and manage their opportunities. Admins approve opportunities before

publication.

Opportunity details include region, type, work arrangement, eligibility and expiry

Brief §7, A9

MKP-

05

Professionals search opportunities by region, type and work arrangement

Brief §7

06

Opportunity details include region, type, work arrangement, eligibility and expiry

Role detail and eligibility page

Brief §7

MKP-

07

Professionals apply by selecting relevant profile content

Brief §7

MKP-

08

Professionals track their applications and receive status updates

Brief §7

MKP-

09

Organisations receive and review applications, shortlist applicants and manage application

statuses

Brief §7

MKP-

1 0

Organisations contact applicants through permitted channels (see 6.1 1 )

Brief §7

MKP-

1 1

Users can report listings

Brief §7

MKP-

1 2

Admins review organisations and reported listings, moderate suspicious or expired

opportunities, manage access, audit trails and retention, and monitor marketplace integrity

Brief §7

MKP-

1 3

The data model supports licensed third-party listings, with source, attribution, authorisation,

source verification and expiry fields. No feed import is built.

E3-A6, A1 0

MKP-

1 4

Brief §1 0

MKP-

1 6

Controlled by a feature flag on the server and in the UI. Enabled in staging for testing.

Disabled in production until ProoveMe gives written authorisation.

Brief §7

6.11​Marketplace messaging (MSG): built, tested and disabled in production

ID

Requirement

Source

MSG-

01

Secure, permission-controlled messaging between professionals and organisations,

limited to opportunity and application conversations

E3-A2

Brief §7

6.11​Marketplace messaging (MSG): built, tested and disabled in production

ID

Requirement

Source

MSG-

02

Each conversation is linked to an opportunity or application

E3-A2, A8

MSG-

03

Text messages only, with no attachments

A8

MSG-

04

E3-A2, Brief

Add. B

05

Brief Add. B

06

E3-A2

Users can report and block. Admins can moderate and investigate.

Rate limits and spam controls

07

E3-A2

6.12​Partner and cohort foundation (PTN)

ID

Requirement

Source

PTN-

01

Partner organisation and programme records

E3-A4

6.12​Partner and cohort foundation (PTN)

ID

Requirement

Source

PTN-

01

02

Partner user roles and permissions

E3-A4

PTN-

03

Partner approval, using the same process as organisation verification

E3-A4

PTN-

04

Invitation codes or links that associate professionals with a programme, with expiry

and abuse limits

E3-A4, Brief Add.

A, A1 1

PTN-

05

Professionals consent before being linked to a programme

Brief §1

06

A basic list of linked professionals who have consented to share. No public

participant lists.

Brief §1 , Add.

A, A1 1

PTN-

07

E3-A4

6.13​Monetisation readiness (BIL)

ID

Requirement

Source

BIL-

01

Data model for plans, subscriptions and entitlements

E3-A5

BIL-

02

Entitlement checks enforced on the server and controlled by feature flags

03

Admin settings to configure plans and entitlements

E3-A5

BIL-

04

6.14​Referrals, analytics and experiments (ANL)

ID

Requirement

Source

ANL-

01

Funnel events: visit, sign-up, first Impact published, evidence added, first share, returning

use, organisation approved, search, profile viewed, shortlist and contact

Brief §1 1 ,

Add. A

6.14​Referrals, analytics and experiments (ANL)

ID

Requirement

Source

ANL-

02

Campaign and referral tokens, with first-touch and invited-by fields

Brief Add. A

ANL-

03

Event tracking respects consent

Brief §1 0,

Add. A

04

Aggregate dashboard in the admin panel

05

Onboarding copy and referral prompts are configurable, with feature flags and privacy-safe

measurement

06

Referral attribution never exposes private identities

Brief Add. A

6.15​Notifications (NOT)

ID

Requirement

Source

NOT-

01

Email notifications for account verification, password reset, verification invitations and

responses, organisation and partner invitations, approval decisions, and contact requests

and responses

Brief §5, §6,

Add. A

02

Marketplace email notifications for application status updates and new messages (disabled

with the marketplace)

Brief §7

NOT-

03

Statuses are also shown in the user's dashboard. No SMS or push notifications.

A1 3

6.16​Administration panel (ADM)

ID

Requirement

Source

ADM-

01

View, suspend and reinstate professionals and organisations

Brief §1

02

Admin roles: super admin and moderator

Brief §1 ,

A1 4

ADM-

03

Approval queue for organisations and partners

Brief §6,

E3-A4

ADM-

04

Review queue for flagged verifications

E3-A3

ADM-

05

Handling of reported profiles, contact requests, listings and messages

Brief §1 ,

Add. B

ADM-

06

Marketplace moderation (see MKP-1 2)

Brief §7

ADM-

07

Feature flag management, with every change logged

Brief §9,

A1 5

ADM-

08

Plan and entitlement settings

E3-A5

09

Audit log viewer

Brief §9

ADM-

1 0

Product health and analytics aggregates

Brief §1 ,

Add. A

ADM-

1 1

Access to sensitive AI inputs, outputs and logs, and to private evidence, is restricted,

requires a recorded reason, and is logged

E3-AI

ADM-

1 2

Suspicious-access alerts

Brief Add. B

ADM-

1 3

Configuration of countries, locations, onboarding copy and referral prompts

Brief §2,

Add. A

6.17​AI integration (INT)

This section covers only the full-stack side of the AI features. How the AI works is covered in the separate AI document.

See section 4.1 for the flow.

Communication and security

ID

Requirement

Source

INT-

01

The frontend never calls the AI service or AI providers directly. All AI requests go from the

frontend to the ProoveMe backend.

E2, A26

INT-

02

Before calling the AI service, the backend checks the user's identity, permissions, AI consent

and usage limits

E2, E3-B7,

E3-AI

All AI calls go through one backend integration layer, so the AI provider can be changed

without changing the rest of the platform

E2

INT-

05

The backend sends only the data needed for each request, applying the data-minimisation

rules defined by the AI team

E2, E3-AI

INT-

07

AI requests such as CV analysis run as background jobs. The frontend shows progress and

the job status.

E3-AI

INT-

08

The backend checks that the AI result has the expected structure before saving it. Invalid

results are treated as failures.

Brief §5A,

A26

INT-

09

AI results are saved with "AI draft" status and are shown to the user for approval, editing or

rejection (see PRO-06, PRO-07)

Brief §5A

INT-

1 0

When the AI fails or is unavailable, the user sees a clear message, can retry, and can continue

with the manual workflow

E3-AI

Consent, limits and records

ID

Requirement

Source

INT-

1 1

AI consent and preference settings, with an opt-out to the manual workflow. Users can change

their choice later. The wording is provided by ProoveMe (A1 7).

E2, E3-

B7

1 2

Per-user AI usage limits and rate limiting, configurable in the admin panel

E3-AI

INT-

1 3

User corrections and rejections of AI suggestions are recorded

E3-AI

INT-

1 4

AI requests and results are logged, with restricted, recorded access and retention controls (see

ADM-1 1 )

E3-AI

INT-

1 5

Stored AI inputs and outputs follow the same deletion rules as the user's other data

E3-B7

INT-

1 6

The draft review screen shows which parts of an AI draft come from the professional's own

material and which are AI suggestions or assumptions that need the professional's confirmation.

The AI service marks these parts (AI SRD, AI-03).

Brief

§5A

INT-

1 7

When the AI finds fewer than three Impacts, or none, the professional sees a clear explanation and

is offered the next steps: answer follow-up questions, add more information or create Impacts

manually

Brief

§5A

Feature

Full-stack covers

CV analysis and Impact drafts

Upload, background job, draft review screen, approve, edit

and reject

PRO-01 , PRO-06,

Section

Follow-up questions

Question screens with skip, save and return later

PRO-1 1

Section

Update suggestions for

existing Impacts

Trigger when the user adds information, review screen,

version history

PRO-09, PRO-1 3

PRO-07

Profile headline and summary

Editing screen with approval

PRO-1 4

Evidence analysis

Display as a suggestion, kept private from employers

EVD-07

Verification invitations

Optional AI-drafted invitation text, editable before sending

VER-1 0

Semantic employer search

Search screens and search index. The AI service provides

the text processing (A27).

EMP-03

7.1​Security (SEC)

ID

Deliverable

Source

SEC-

02

Build role-based and object-level authorisation checks, enforced in the API and the database

layer

E2

Build separate permission sets for professional, organisation, partner and admin accounts

E2

SEC-

04

Build tenant isolation so no user can reach another user's information through changed API

requests or object IDs, with automated tests that prove it

E2

SEC-

05

Set up secure file storage with malware scanning and short-lived, permission-checked file

access

Brief §9

SEC-

06

Build rate limiting, anti-enumeration controls, bot controls and bulk-export limits on the

endpoints that need them

Brief

Add. B

SEC-

07

Build one audit log service that records sensitive actions. Other features write to it instead of

keeping their own logs.

Build consent capture and consent records for AI processing, analytics, employer search

visibility and search-engine indexing

Build one background job system for long-running operations, with progress shown to the user.

All features use it.

E3-AI

PERF-

04

Build server rendering for all public pages

Brief

§8

ACC-

02

§2

04

Build empty, loading, success, error, restricted-access and consent states for every screen in

section 1 6.1

7.5​SEO (SEO)

ID

Deliverable

Source

SEO-

01

Build page metadata, an XML sitemap, robots rules and canonical URLs for all public pages

Brief

§1 0

02

Brief

§1 0

SEO-

03

04

Add structured data for Organisation, WebSite, BreadcrumbList and appropriate public content

Build indexing controls so only public, consented profile and Impact content is indexed. Private

evidence, employer-only data, application details and unlaunched marketplace pages are never

indexed.

Set up a clear page hierarchy, internal links and image alt text on public pages

SEO-

05

Do not generate location pages automatically

Brief

§1 0

SEO-

07

Build public page templates that support answer-focused FAQs, visible authorship (author and

last-updated details) and location-aware content where it has real editorial value. ProoveMe

provides the content (A1 6).

Brief

§1 0

7.6​Localisation and configurability (LOC)

ID

Deliverable

Source

LOC-

01

Build the interface in English, with all interface text kept in translation files so other languages can

be added later

§2

Brief

§1 0

7.6​Localisation and configurability (LOC)

ID

Deliverable

Source

§2

LOC-

02

Build configuration for countries, locations, time zones and currencies, managed in the admin

panel (ADM-1 3), with nothing hard-coded to Nigeria

Brief

§2

LOC-

03

Load Nigerian states and cities, support +234 phone numbers, and apply local date and number

formatting

Produce responsive Figma designs for every screen in section 1 6.1 , an approved design

system, reusable components and all screen states (ACC-04)

Brief §8

DES-

03

Produce clickable prototypes

Brief §8

DES-

04

06

Produce a brand and social asset pack of 1 0–1 2 core templates, including platform

previews and founding-professional campaign graphics, in editable Figma and

export-ready files

Brief §5A

(Design

deliverables)

DES-

E2, A24

DES-

08

Design the mobile version of each screen group, covering at least: Public (mobile hero,

navigation and registration), Professional (simple step-by-step creation and preview),

Employer (search filters and candidate cards), Partner (responsive read-only essentials),

Marketplace (opportunity cards, apply flow and status)

Brief §8

E3-B8

TST-

1 0

Run user acceptance testing (UAT) with ProoveMe at the end of each milestone,

against that milestone's acceptance criteria

Brief §5A (Commercial

Demonstrate the full journey with the AI team: CV upload, AI proposes Impacts,

follow-up questions, review, edit or reject, and publication of an approved profile.

Include the case where fewer than three Impacts are found (INT-1 7).

Write the documentation listed in A20: technical architecture, API documentation, deployment

and operations runbook, and admin guide

E2

DEL-

03

Provide a 90-day defect warranty after launch

Brief §5A,

E2

DEL-

04

Analytics

Funnel and referral tracking

Organisation verification at launch uses work email verification, organisation details and admin review. Admins

check registration details manually against public registries. Automated registry lookups are optional.

A3

Verifier identity is checked through email confirmation and the verifier's stated name, role and relationship. A

work-domain match is recorded, and mismatches go to admin review. No ID documents or external profiles are

checked. Verifiers do not need a ProoveMe account.

A4

A verifier sees only the claim they are asked to confirm, not the professional's private profile or evidence.

A5

A material change is any edit to the claim content of an Impact that has linked evidence or verified status.

Formatting-only edits do not count. The professional is warned before saving. The exact rule will be confirmed

during design.

A6

Visibility levels are private, verified employers only, and public. Evidence is private by default. Search-engine

indexing of a profile is off by default and enabled by the professional.

A7

In employer discovery, contact happens through contact requests. Once a request is accepted, the professional's

chosen contact details are shared. In-platform messaging exists only within the marketplace.

chosen contact details are shared. In-platform messaging exists only within the marketplace.

A8

Marketplace messaging is text only, and each conversation is linked to an opportunity or application.

A9

Opportunities require admin approval before publication.

A1 0

Notifications are by email, with statuses shown in the dashboard. No SMS or push notifications.

A1 4

ProoveMe admin roles are super admin and moderator. Admin accounts use multi-factor authentication.

Only super admins can change feature flags, and every change is logged. The production marketplace is

activated only after ProoveMe's written authorisation.

A22

Data export is provided in a machine-readable format (for example JSON).

A23

The marketing site contact form sends enquiries to a ProoveMe email address.

A27

For semantic search, the AI service turns profile and search text into a form the search index can use. The

full-stack build stores the index, runs the searches, applies permissions and shows the results.

A28

An Impact the professional creates manually, or creates through guided questions without AI (A33), starts with

"user-approved" status, because the professional wrote it.

A29

An Impact becomes "evidence-backed" when the professional links at least one evidence item to it and confirms

that the evidence supports the claim. AI may suggest the link, but only the professional's confirmation changes

the status.

A30

After a material change (A5), an evidence-backed or verified Impact returns to "user-approved" until the

professional reconfirms the evidence or a new verification is completed. The previous version and its status stay

in the version history.

A33

Guided questions (PRO-01 c) may be AI input or not. Until ProoveMe confirms: if the professional has given AI

consent, the answers are sent to the AI and the resulting Impacts start as AI drafts. Without AI consent, the

answers form an Impact directly, which starts as user-approved (A28).

A34

Users can report a profile. ADM-05 includes reported profiles, so a way to report one is assumed (PRF-1 0).

16.1​Screen list

Each screen is designed (DES-02), built with all its states (ACC-04) and tested (TST-01 ) . Each screen is one frontend task

(PLN-06).

Marketing website

Screen

What it does

Requirements

S-

01

Homepage

Explains ProoveMe in the first screen with a

real product preview, routes each audience

and shows one main sign-up action

MKT-01 , MKT-02,

MKT-06, MKT-07

Requirements

S-

01

02

Audience landing pages

(Professionals,

Employers/Recruiters, Partners)

One page per audience

MKT-03

S-

03

How it works

Explains the product

MKT-04

S-

04

Sample anonymised Impact

Shows an example Impact

MKT-04

S-

05

Privacy and trust

Explains privacy, evidence and verification

MKT-04

S-

06

FAQ

Answer-focused frequently asked questions,

with authorship shown

MKT-04, SEO-07

S-

07

Contact

Contact form that sends to ProoveMe's email

address

MKT-05

S-

08

Legal pages

Privacy policy, terms and other legal pages,

with text from ProoveMe

MKT-04, A1 7

S-

09

Cookie consent banner

Consent for analytics and non-essential

cookies

MKT-08, ANL-03

S-

1 0

Employer entry page

Explains the employer proposition and links to

the account request

ORG-01

Accounts

Screen

What it does

Requirements

S-

1 1

Sign up

Email registration with minimal fields, and Google

sign-in

AUTH-01 , AUTH-02,

AUTH-04

What it does

Requirements

S-

1 2

Email verification

Confirms the email address

AUTH-01

1 3

Sign in

Email and Google sign-in

AUTH-02, AUTH-04

S-

1 4

Password

recovery

Request and set a new password

AUTH-03, AUTH-04

Professional area

Screen

What it does

Requirements

S-

1 5

Choose a start

path

Offers the four start paths and continues saved progress

PRO-01 , PRO-01 e

S-

1 6

AI consent

Asks for AI consent before any AI path, with the option to use

the manual path

INT-1 1 , PRV-06

S-

1 7

CV upload

Upload a CV, see file rules, and see background progress

PRO-01 a, PRO-02,

INT-07, INT-1 0

S-

1 8

Free-text entry

Write experience in free text and send it for analysis

PRO-01 b, PRO-03,

INT-07

S-

1 9

Guided

questions

Answer experience questions one step at a time. With AI

consent, the answers go to the AI as in S-1 8 (A33).

PRO-01 c, PRO-03, A33

S-

20

AI draft review

Approve, edit or reject each AI-proposed Impact separately.

Shows which parts come from the professional's material and

which need confirmation. Explains what to do when few or no

Impacts are found.

PRO-06, PRO-07,

INT-09, INT-1 3, INT-1

6,

INT-1 7

S-

21

Follow-up

questions

Answer, skip or save follow-up questions

PRO-1 1

S-

22

Impact editor

Create or edit an Impact as Situation, Decision, Action,

Outcome and Evidence, with guided prompts. Warns before a

material change.

PRO-01 d, PRO-04,

PRO-05, PRO-1 0

S-

23

Impact detail

and version

history

Shows an Impact, its status and its previous versions

PRO-07, PRO-09

S-

24

Suggested

updates

Review AI-suggested new or updated Impacts and approve,

edit or reject them

PRO-1 3, INT-09

S-

25

Dashboard

Impacts, evidence, profile visibility and pending actions

PRO-08, PRO-1 2,

NOT-03

26

Evidence

manager

Add, view and remove evidence, set visibility per item, and

see AI evidence suggestions

EVD-01 to EVD-04,

EVD-07

Evidence sharing

Create, view and revoke permissioned evidence links

EVD-05

S-

27

28

Profile editor

Headline, summary (with optional AI help), location and phone

number

PRO-1 4, PRO-1 5, PRF-

01

29

Profile preview

and publish

Preview the profile and choose which Impacts to publish

PRF-01 , PRO-08

S-

30

Privacy and

visibility settings

Profile and Impact visibility, employer search, contact details,

search-engine indexing

PRF-03, PRF-04,

PRF-06, PRF-07

S-

31

Share

Share a profile or Impact by link, QR code, WhatsApp or

LinkedIn

PRF-05

S-

32

Verification

requests

Invite a verifier for one claim, optionally with AI-drafted text,

and track responses

VER-01 , VER-02,

VER-1 0

LinkedIn

S-

33

Contact

requests

Accept or decline contact requests, report spam and block

organisations

CON-02, CON-03

Screen

What it does

Requirements

S-

34

Programme

invitation

Accept a partner programme invitation and give consent

PTN-04, PTN-05

Screen

What it does

Requirements

S-

34

35

Account settings

AI preferences, data export and account deletion

INT-1 1 , PRF-08,

PRF-09

Public pages for the main web application

Screen

What it does

Requirements

S-

36

Public profile

Published profile at a stable URL, server-rendered. Report the

profile.

PRF-02, PRF-1 0,

PERF-04, SEO-03

S-

37

Public

Impact page

One published Impact, with share previews

PRF-05, SEO-03

S-

38

Verifier claim

page

The verifier confirms their identity details, then confirms,

declines or comments on one claim. No account needed.

VER-03, VER-04,

VER-05

Employer area

Screen

What it does

Requirements

S-

39

Organisation account

request

Work email, organisation name, website, country and

registration number

ORG-02, ORG-03,

ORG-05

S-

40

Awaiting approval

Shown until an admin approves the organisation

ORG-04

S-

41

Team management

Invite team members and set admin or member roles

ORG-06

S-

42

Employer workspace

Saved searches, shortlists and permitted activity

EMP-1 1

S-

43

Search and results

Filters, keyword and natural-language search, and the

reason for each match

EMP-01 to EMP-07,

EMP-1 2

S-

44

Candidate view

Permitted profile information and evidence status.

Report the profile.

EMP-08, EMP-1 4,

PRF-1 0

S-

45

Shortlists

Shortlists organised by recruitment project

EMP-09

S-

46

Saved searches

View and rerun saved searches

EMP-1 0

S-

47

Send contact request

Send a contact request with context

CON-01 , CON-05

Partner area

Screen

What it does

Requirements

S-

48

Partner workspace

Programmes, invitation codes and links

PTN-01 , PTN-02,

PTN-04

49

Linked

professionals

Basic list of linked professionals who consented to

share

50

Opportunity search

Search by region, type and work arrangement

MKP-05

S-

51

Role detail and

eligibility

Opportunity details and eligibility. Report a listing.

MKP-03, MKP-06,

MKP-1 1

S-

52

Apply

Choose the profile content to include and apply

MKP-07

S-

53

My applications

Application list and status updates

MKP-08

S-

54

Manage

opportunities

Organisations create, edit and close opportunities, and see

approval status

MKP-01 to MKP-04

S-

55

Applicant review

Review applications, shortlist applicants and change

application status

MKP-09, MKP-1 0

S-

56

Messages

Text conversations linked to an opportunity or application,

with report and block

MSG-01 to MSG-05

Admin panel

Screen

What it does

Requirements

S-

57

Admin sign-in

Sign-in with multi-factor authentication

AUTH-06

S-

58

Users and

organisations

View, suspend and reinstate professionals and

organisations. Revoke organisation verification.

ADM-01 , ORG-08

S-

59

Approval queue

Approve or reject organisations and partners, with the

manual registry check

ADM-03, ORG-04,

PTN-03, A2

S-

60

Verification review

queue

Uphold or remove flagged verifications

ADM-04, VER-08

S-

61

Reports and

moderation

Reported profiles, contact requests, listings and

messages

Reports and

moderation

Reported profiles, contact requests, listings and

messages

ADM-05, CON-04,

MSG-04

S-

62

S-

62

Marketplace

moderation

Approve opportunities and moderate suspicious or

expired listings

ADM-06, MKP-04, MKP-1

2

S-

63

Feature flags

Change feature flags (super admin only), with a change

log

ADM-07, A1 5

ADM-06, MKP-04, MKP-1

ADM-07, A1 5

S-

64

Plans and

entitlements

Configure plans and entitlements

ADM-08, BIL-03

65

Audit log

Search and view the audit log

ADM-09

S-

66

Analytics

dashboard

Product health, funnel and referral aggregates

ADM-1 0, ANL-04

S-

67

Sensitive data

access

Request access to sensitive AI data or private evidence

with a recorded reason

ADM-1 1

S-

68

Alerts

Suspicious-access alerts

ADM-1 2

S-

69

Configuration

Countries, locations, onboarding copy, referral prompts

and AI usage limits

ADM-1 3, ANL-05,

INT-1 2, LOC-02

16.2​Impact status rules

These rules are defined once here (PLN-05). Each Impact has exactly one of the four statuses in PRO-07 at a time.

Publishing and visibility are separate settings and do not change the status.

Statuses

Status

Meaning

AI draft

Proposed by the AI and not yet approved by the professional. Never published or shown to

employers.

What causes it

Who can do it

Requirements

(new)

AI draft

The backend saves a valid AI

result

Backend, after

INT-08 checks

INT-08, INT-09

User-approved

The professional creates an

Impact manually

Professional

PRO-05, A28

AI draft

User-approved

The professional approves the

draft, with or without edits

Professional

PRO-06

AI draft

(removed)

The professional rejects the

draft. The rejection is recorded.

Professional

PRO-06, INT-1 3

User-approved

Evidence-

backed

The professional links evidence

and confirms it supports the

claim

Evidence-backed

User-approved

User-approved or

evidence-backed

Independently

verified

A verifier confirms the claim and

the identity check passes, or an

Professional

EVD-01 , A29

The professional removes the

last confirmed evidence item

admin upholds a flagged

verification

Verifier, admin

VER-04 to

VER-08

Independently

verified

Previous status

An admin removes a flagged

verification

Admin

VER-08

Evidence-backed or

independently

verified

User-approved

The professional saves a

material change

Professional

PRO-1 0, VER-

09, A5, A30

Rules that apply to every change

●​ The AI can never change a status. Only the people listed above can, through actions checked by the backend. (INT-06,

VER-06)

●​ Every change writes one entry to the audit log (SEC-07): the Impact, the old and new status, who made the change and

when. (PRO-09, VER-07)

●​ Only Impacts with user-approved status or higher can be published. (PRO-06, PRO-08)

●​ An edit to a published Impact creates a new version. The previous version stays in the version history. (PRO-09)

●​ A material change affects only the Impact that changed. Other verified Impacts keep their status. (PRO-10)

Holds

Requirements

User account

Email, sign-in method, email verification, account type, MFA for

admins

AUTH-01 to AUTH-06

Professional profile

Headline, summary, location, optional phone, profile URL, visibility

and search settings

PRO-1 4, PRO-1 5, PRF-

01 to PRF-07

Onboarding

progress

Chosen start path and saved progress

PRO-01 , PRO-01 e

Impact

Situation, Decision, Action, Outcome, experience type, status

(1 6.2), visibility, published flag

PRO-03, PRO-04,

PRO-07, PRF-03

Impact version

File or link, type, scan result, visibility, linked Impacts

Evidence item, recipient, expiry, revoked flag

Impact, verifier email, invitation token, expiry, number of uses (for

abuse limits), verifier details, identity check result, work-domain

match, response, comment, review outcome

VER-01 to VER-08

Organisation

Type (employer, recruiter, partner), name, website, country,

registration number, verification and approval status

ORG-02 to ORG-05,

ORG-08

Organisation

member

User, organisation, role (admin or member)

ORG-06

Team invitation

Organisation, invited email, role, invitation token, expiry, status

(pending, accepted, expired, cancelled)

ORG-06, NOT-01

Shortlist and

recruitment project

Organisation, project, shortlisted professionals

EMP-09

Saved search

Organisation, search criteria

EMP-1 0

Profile view

Organisation, professional, time

EMP-1 4

Contact request

Organisation, professional, context, status, shared details

CON-01 , CON-02

Report and block

Who reported or blocked whom or what, reason, admin outcome

CON-03, CON-04, MKP-1

1 , MSG-04, ADM-05

Opportunity

Organisation, type, region, work arrangement, eligibility, expiry,

approval status, third-party listing fields

MKP-01 to MKP-04,

MKP-1 3

Application

Opportunity, professional, selected profile content, status

MKP-07 to MKP-09

Conversation and

message

Opportunity or application, participants, text messages

MSG-01 to MSG-03

Partner programme

Partner organisation, programme details

PTN-01 , PTN-02

Programme

invitation

Programme, code or link, expiry, use limits

Programme link

PTN-04

Programme, professional, consent

PTN-05, PTN-06

Plan and

entitlement

Plans, entitlements, assignment to accounts

BIL-01 to BIL-04

Record

Holds

Requirements

Consent record

User, consent type, wording version, time, withdrawal

INT-1 1 , PRV-06, ANL-03

AI job

Request type, user, status, progress, result or error

INT-07, INT-1 0

AI suggestion

Proposed content, linked Impact, outcome (approved, edited,

rejected)

INT-09, INT-1 3, PRO-1 3

AI log

Request and result, with restricted access and retention

INT-1 4, INT-1 5, ADM-1 1

Search index entry

Published, consented content prepared for search

EMP-03, EMP-06, A27

Analytics event and

referral token

Funnel event, campaign or referral token, first touch, invited by

ANL-01 , ANL-02,

ANL-06

Notification

Recipient, type, email status

NOT-01 to NOT-03

Feature flag

Flag, value per environment, change log

ADM-07, SEC-1 1 ,

MKP-1 6

Configuration

Countries, locations, time zones, currencies, onboarding copy,

referral prompts, AI limits

ADM-1 3, LOC-02,

INT-1 2

Audit log entry

Who did what, to which record, when, and the recorded reason

where needed

SEC-07, ADM-09, ADM-1

1

ADM-

02, TST-01 , all data records in 1 6.3, marketplace

readiness (MKP-1 3, MKP-1 6, MKP-1 7), PRV-04,

PRV-05, PERF-01 , PERF-03, ACC-01 , ACC-04,

LOC-01 to

LOC-03, the AI integration layer (INT-01 to INT-08),

INT-1 2 with default limits (changed through S-69 from

M5), the email service and account emails (NOT-01 ) ,

S-1 1 to S-1 4, S-57

Users and admins can sign up

and sign in in staging, hosted in

the UK or EU. Permission and

tenant-isolation tests pass.

Monitoring and performance

checks run on every build.

M3

Marketing

website and

professional

core

MKT-01 to MKT-08, PRO-01 to PRO-1 5 (including

PRO-01 a to PRO-01 e), EVD-01 to EVD-08, PRF-01 to

PRF-1 0, INT-09 to INT-1 1 , INT-1 3 to INT-1 7, PRV-06,

NOT-03, ADM-05, the status rules in 1 6.2, SEO-01 to

SEO-05, SEO-07, PERF-04, TST-1 1 , S-01 to S-1 0, S-1

5 to S-31 , S-35 to S-37, S-61

A professional can complete

each start path, approve

Impacts, add evidence, publish

and share a profile. The full AI

journey is demonstrated (TST-1

1 ) .

M4

Verification,

organisations,

discovery and

contact

VER-01 to VER-1 0, ORG-01 to ORG-08, EMP-01 to

EMP-1 4, CON-01 to CON-06, ADM-03, ADM-04,

NOT-01 (verification, organisation, approval and

contact emails), SEC-06, SEC-1 0, S-32, S-33, S-38

to S-47, S-59, S-60

An admin approves an

organisation. A verified

organisation. A verified

employer can search, shortlist

and send a contact request. A

and send a contact request. A

verifier can confirm a claim,

verifier can confirm a claim,

and an admin can review a

flagged verification.

M5

Admin, partners,

analytics and

monetisation

readiness

ADM-01 , ADM-07 to ADM-1 3, PTN-01 to PTN-07,

ANL-01 to ANL-06, BIL-01 to BIL-05, NOT-01 (partner

invitation emails), S-34, S-48, S-49, S-58, S-63 to S-69

Admins can moderate,

manage flags, set AI limits and

view the audit log. Partners

view the audit log. Partners

can invite and see consented

professionals.

M6

Marketplace and

messaging

(disabled in

production)

MKP-01 to MKP-1 2, MKP-1 4, MKP-1 5, MSG-01 to

MSG-07, NOT-02, ADM-06, TST-09, S-50 to S-56, S-62

The full marketplace and

messaging work in staging

(TST-09). The flag is off in

production.

M7

Hardening and

launch

TST-02 to TST-08, TST-1 0, ACC-05, PERF-02, OPS-01

, OPS-03, OPS-04, SEC-09, PRV-02, PRV-07, DEL-

02

A full run of the automated

B: Employer

discovery

In the initial scope

(section 2)

ORG-01 to ORG-08, EMP-01 to EMP-1 4

(including the semantic search screens and

index, EMP-03), CON-01 to CON-06, ADM-03

index, EMP-03), CON-01 to CON-06, ADM-03

(organisation approvals), NOT-01 (organisation,

approval and contact emails)

PTN-01 to PTN-07, ADM-03 (partner

approvals), NOT-01 (partner invitation emails)

M5. Partner

approvals use the

approval queue

built in M4 (S-59).

D: Marketplace

readiness

In the initial scope

(section 2)

MKP-1 3, MKP-1 6, MKP-1 7, and the

Opportunity, Application and Conversation

E: Marketplace

launch

MKP-01 to MKP-1 2, MKP-1 4, MKP-1 5, MSG-01

to MSG-07, NOT-02, ADM-06, TST-09

ProoveMe's later

answers ask for it to be

built, tested and disabled

in production (E2, E3-B8,

E3-A2).

F:

Monetisation

Data model, entitlement

checks and admin

settings are built

(section 2, E3-A5). The

BIL-01 to BIL-05, ADM-08

The supplier will design, build, test and hand over the AI components of ProoveMe: AI-led Impact discovery, drafting and

user-triggered ongoing management, AI-assisted evidence analysis, AI support for explainable employer discovery, and the

safeguards around them. Every AI output is a proposal. Publication and claim status are controlled by the professional and

by deterministic server rules, never by a model.

The AI components must work inside the wider platform: professional, employer and admin roles, evidence storage,

verification workflows and feature flags are delivered under the platform scope.

Brief requirement

How this SOW meets

it

Reference

Identify potential Impacts from a CV or entered

experience

Extraction and

candidate detection

over supplied

information only

AI-01, AI-02

Brief requirement

How this SOW meets

it

Reference

Generate proposed Impact drafts using

Situation, Decision, Action, Outcome, Evidence

Drafting with

provenance tags on

every statement

AI-03

Ask targeted follow-up questions only where

necessary

Gap-driven questions

with agreed limits

AI-04

Distinguish confirmed information from

assumptions; never invent achievements,

figures, evidence or verification

Provenance tags,

programmatic checks,

separate verification

pass

AI-03, AI-05, section 5

Individual approval, editing or rejection; nothing

published automatically

Per-Impact review

flow; publishing

enforced server-side

AI-06, section 4

Save, publish and update through the

dashboard

Integration with the

platform dashboard

AI-06, platform SOW

Suggest new Impacts or revisions when new

information is added, subject to approval

User-triggered

suggestion queue

AI-07

Keep AI drafts, user-approved, evidence-backed

and verified claims separate

Four-state claim

model

Support employment, education, volunteering, freelance,

informal and other legitimate work

AI-02, section 3.2

Intuitive process, no unnecessary questions, no metrics users

lack

AI-04, sections 9 and 11

Sections 4 and 5

Client requirement

Section 5.1

AI-07

Evidence analysis allowed under access controls, no

independent verified status

AI-08, section 4

Explainable, permission-controlled employer discovery in the

initial platform

Insufficient CV information: identify what is supported and

guide the user instead of fabricating

Ongoing management is user-triggered; no change applied

without explicit approval

3. AI capabilities in scope

ID

Capability

What it does

Trigger

AI-01

CV and experience

ingestion

Validates files, extracts text (native parsing first, OCR

fallback), checks quality, structures roles, dates,

projects and stated outcomes with source

references

CV upload or

manual entry

AI-02

Impact candidate

detection

Identifies contributions, decisions, actions and

outcomes across employment, education,

volunteering, freelance and informal work

After ingestion

AI-03

SDAOE drafting

Generates Situation, Decision, Action, Outcome and

Evidence drafts, each statement tagged as stated in

source, inferred or needs confirmation

After detection

AI-04

Targeted follow-up

Asks questions only where a gap blocks a defensible

statement; does not require metrics the user lacks

During drafting

AI-05

Verification pass

Separate check comparing each drafted claim

against source text and user answers; flags

Before display

unsupported figures, names and outcomes before

the user sees them

AI-06

Review and approval

support

Per-Impact approve, edit or reject; suggestion queue

with before and after comparison

User action

AI-07

Ongoing suggestions

Proposes new Impacts or revisions to existing or

published Impacts when the user adds experience or

evidence, or asks for a review

User-triggered

only

AI-08

Evidence analysis

Reads uploaded evidence under access controls and

suggests whether it supports a claim; never changes

verified status

User-triggered

AI-09

Explainable

discovery support

Retrieval and matching that show why a profile

matched (matched Impact text, skills, outcomes),

with no scores and no automatic rejection

Employer

search

AI-10

Duplicate detection

Flags overlapping Impacts across roles or uploads for

user resolution

During drafting

and review

AI-11

Manual alternative

Full manual path for users who opt out of AI; AI-free

Impact creation and editing

User choice

AI-12

Provider abstraction

Provider-independent layer so models can be

swapped without product changes; configuration of

provider, region and retention settings

Platform

AI-13

Evaluation and

3.1 End-to-end journey

13.​The professional chooses a start path: manual entry or CV upload. Progress is saved. AI use needs the user's

consent, and a manual path is always available.

14.​For an upload, the platform validates and malware-scans the file before AI processing begins. Text is extracted,

and the quality of the extraction is checked.

15.​The system shows the structured experience it found (roles, dates, projects) so the user can correct it before

anything is drafted.

16.​The system lists candidate Impacts, each linked to the passage in the source that supports it.

17.​For each candidate, a draft is generated using Situation, Decision, Action, Outcome and Evidence, with every

statement tagged as stated in source, inferred or needs confirmation.

18.​Where a gap blocks a defensible statement, the system asks a short targeted question. The user can answer, skip

or say they do not know.

19.​A verification pass checks each statement against the source and the user's answers, and flags anything

unsupported before the user sees it.

20.​The user approves, edits or rejects each Impact individually. Possible duplicates are shown for the user to merge

or dismiss.

21.​Approved Impacts are saved. Publishing is a separate user action through the dashboard.

22.​Later, when the user adds experience or evidence, or asks for a review, the system proposes new Impacts or

revisions in a suggestion queue. Nothing changes until the user approves it.

3.2 Capability detail

Ingestion (AI-01). Native PDF and Word parsing first, OCR as a fallback for scanned or photographed documents.

Supported formats, size and page limits are set in the platform scope and enforced before processing. Low-quality or

unsupported files receive a clear message and a route to manual entry. Content is treated as untrusted input throughout.

Candidate detection (AI-02). Looks across employment, education, volunteering, freelance, informal and community

work. It separates responsibilities from outcomes, so a list of duties is not presented as an achievement. Internal

confidence is used to order and filter candidates; it is not shown to employers and is not a score of the person.

Drafting (AI-03). Drafts are in plain language and keep the user's own wording where possible. Each statement carries a

visible provenance label. Style options such as concise or detailed can be added later without changing the data model.

Follow-up questions (AI-04). Questions are asked only for gaps that block a defensible statement. Metrics are never

required. The proposed limit is three questions per Impact and ten per session, to be confirmed after testing.

Verification pass (AI-05). A separate step, not the drafting call, compares claims with source text. Figures and named

entities are checked by code, not by the model. Failures send the item back for rewriting or mark it as needs confirmation.

Review and approval (AI-06). Every Impact has an explicit approve, edit or reject action. Rejections are remembered so

the same suggestion is not repeated unprompted. The platform stores version history for edits.

Ongoing suggestions (AI-07). Triggered by new information the user adds or by an explicit request. Suggestions show

what would change, why, and which new input prompted it, as a before and after comparison. Suggested changes to

published Impacts apply only after approval.

Evidence analysis (AI-08). Works on evidence the user has uploaded, under the same access controls as the evidence

itself. The output is a short summary and a suggested relationship to the claim: supports, partly supports, does not appear

to support, or unclear. It is shown to the professional first. It never changes the claim state, and evidence content is never

sent to employers by AI. Who may see the analysis result is an open item (section 20).

Duplicate detection (AI-10). Finds overlapping Impacts across roles or uploads, including the same project described

differently, and asks the user to merge or keep both.

Manual alternative (AI-11). Impacts can be created and edited without AI. Users who opt out lose no core functionality.

Consent can be changed later, and the effect on data already processed follows the retention rules in section 6.4.

4. Claim states and provenance

The data model keeps four states separate, with an audit trail for each change:

5.​ AI draft: generated by the system, not yet reviewed.

6.​ User-approved: accepted or edited by the professional.

7.​ Evidence-backed: linked to supporting evidence by the professional.

8.​ Independently verified: confirmed through the verification workflow by a person or third party.

AI services have no write path to the evidence-backed or verified states. AI may suggest a link between a claim and

evidence, but the professional confirms it. Edits to a published Impact keep version history, and the effect of an edit on

evidence-backed or verified status is applied by platform rules agreed during design.

Numbers, percentages, currency amounts and named entities in drafts are checked programmatically against

source and user input.

Generation and verification run as separate steps.

Publishing is blocked for anything the user has not approved; this is enforced server-side.

Where fewer than three defensible Impacts exist, the system shows what is supported, explains the gap and

guides the user through questions instead of inventing content.

Per-user scoping on every AI call, with no shared context between users, and permission filtering applied before

any retrieval or ranking.

Consent recorded for AI processing, with a working manual alternative and handling of data already processed if a

user opts out.

The AI components follow data protection by design: collect and send to models only what is needed, use data only for

the purpose the user agreed to, keep it no longer than agreed, and let users see, export and delete their data. Private

information stays private by default.

•​

Audit logging of AI actions that touch personal data, suggestions accepted or rejected, and administrator access to

AI inputs or outputs.

•​

Incident response that includes AI-specific events such as leakage in an output, a provider incident, or a successful

injection.

6.5 Consent and opt-out

AI processing needs the user's informed consent, recorded with a timestamp and wording version. Users can use the

platform without AI, and can withdraw consent later. The granularity of consent (per account, per upload or per feature) is

decided in design. Professional data is not used to train or fine-tune any model without separate written authorisation.

6.6 Personal data fields

CVs often contain details that are not needed to draft an Impact, such as a photo, date of birth, marital status, state of

origin, national ID, phone number or address. The default is to remove these before content is sent to a model and to

exclude them from indexing. ProoveMe confirms the final list, including any field that must never reach an external model

(section 20).

8. Explainable employer discovery (AI support)

The client expects explainable, permission-controlled discovery in the initial platform. The platform must not label

candidates as best or reject them through opaque scores. The AI team provides the retrieval and explanation components.

•​

What is indexed: only content the professional has published and consented to share. Private evidence, contact

details, employer-only data and unlaunched marketplace data are never indexed.

•​

Retrieval: keyword and semantic retrieval combined, so employers can search by experience, capabilities,

outcomes and location, including in natural language. Permission and visibility filters are applied before results are

ranked or shown.

•​

Explanations: each result shows why it matched, for example the matching Impact text, skills and outcomes, and

the evidence status without exposing restricted files. No numeric fit score is shown.

Ordering: a default order based on matched content and recency, shown to employers as an ordinary sort, with

user-selectable sorting. The final default is agreed in design and tested for fairness.

•​

Fairness: protected characteristics and obvious proxies are excluded from indexing. Fairness checks run on the

evaluation set. Results show evidence context and uncertainty. There is no automatic candidate rejection.

Consent-based contact: employers contact candidates only within the professional's permissions. The AI

components give no route around permissions, including through the API.

Deletion and hiding: embeddings and derived data are removed when content is hidden or deleted, and respond

to privacy setting changes.

Logging: search queries are logged in a minimised way, and abuse controls such as rate limits and bulk export

limits are applied with the platform.

•​

Progress and waiting: clear progress while analysis runs. For slow networks and heavy documents, processing can

run in the background with a notification when it is ready, and the user can leave and return.

•​

Resilience: progress is saved, failed uploads can be retried, and nothing is lost if a model call fails.

•​

Accessible interaction: keyboard navigation, readable contrast, accessible forms, and approve, edit and reject

controls that work with assistive technology.

Duplicate Impacts surfaced for

resolution

Seeded duplicates detected on the

test set

Search explainability

Results showing matched content

and reason

Every result shows why it matched;

no scores

asynchronous fallback with

notification

Failure handling

Model error, timeout, low-quality

upload, unsupported file

Clear user message and manual path

in every case; no data loss

Manual path

Full Impact creation without AI

Complete journey works end to end

4. User Personas

3.​Users and roles

Role

Description

Source

Visitor

Anonymous user of the marketing site and public profiles

Brief §4

Professional

Creates Impacts, manages evidence, controls privacy and shares a profile

Brief §1

Verifier

Person invited by a professional to confirm a specific claim. Does not need a

ProoveMe account (A3).

E3-A3

Organisation admin

Manages an employer or recruiter organisation and invites team members

Brief §6,

Add. A

Organisation

Organisation

member

Searches, shortlists and contacts professionals for their organisation

Brief §6

Partner admin

Manages an approved partner organisation or programme

E3-A4

ProoveMe super

admin

Full administrative access, including feature flags and sensitive data (with

justification)

Brief §1 , A1 4

ProoveMe

moderator

Handles approvals, reports and moderation, without access to sensitive data

A24

ProoveMe helps recruit Nigerian professionals and employers for usability testing and the pilot.

5. Core User Flows

5.1 Professional creates and publishes evidence-led work

Actor: Professional. Trigger: The professional registers or signs in and begins onboarding.

1. The professional chooses one of four independent start paths, each a separate flow with its own screens: upload a CV (analysed in the background), describe experience as free text (analysed in the background), answer guided questions one step at a time, or create Impacts manually without AI using guided prompts. Onboarding progress (chosen path and saved progress) is saved on every path so the professional can leave and continue.
2. Before any AI path, the professional is asked for AI consent, recorded with a timestamp and wording version, and may choose the manual path instead. With consent, guided-question answers are sent to the AI and the resulting Impacts start as AI drafts; without consent, the answers form an Impact directly, which starts as user-approved. Consent can be withdrawn later; the granularity of consent (per account, per upload or per feature) is decided in design, and data already processed is handled per that decision. Professional data is not used to train or fine-tune any model without separate written authorisation.
3. For an upload, the platform validates and malware-scans the file before AI processing begins; text is extracted (native parsing first, OCR fallback) and extraction quality is checked. The system then shows the structured experience it found (roles, dates, projects) so the user can correct it before anything is drafted, and lists candidate Impacts, each linked to the supporting passage in the source.

4. For each candidate, a draft is generated using Situation, Decision, Action, Outcome and Evidence, with every statement tagged as stated in source, inferred or needs confirmation. Where a gap blocks a defensible statement, the system asks a short targeted question; the user can answer, skip, or say they do not know. A verification pass then checks each statement against the source and the user's answers and flags anything unsupported before the user sees it.
5. For AI-enabled paths, the frontend sends the request to the backend. The backend checks identity, permissions, AI consent, and usage limits before sending only necessary data to the AI service through one integration layer; every AI call is scoped to the single user with no shared context, and permission filtering is applied before any retrieval or ranking. The result is validated, saved as an AI draft, and the job status is updated; the frontend shows progress, then the draft. Time to first Impact proposals for a text-based CV targets a 95th percentile under 60 seconds with progress shown; on slow networks or heavy documents processing runs in the background with a notification when ready, and the user can leave and return. Progress is saved, failed uploads can be retried, and nothing is lost if a model call fails.
6. The professional reviews each proposed Impact individually and approves (with or without edits) or rejects it; a rejection is recorded and remembered so the same suggestion is not repeated unprompted. Nothing is published automatically. The draft review screen marks which parts come from the professional's own material and which are AI suggestions or assumptions needing confirmation. Possible duplicates across roles or uploads are shown for the user to merge or dismiss. Follow-up questions may be answered, skipped, saved, and returned to later.

7. The professional may instead create or edit an Impact without AI as Situation, Decision, Action, Outcome and Evidence, with guided prompts, and attach files or links; users who opt out of AI lose no core functionality. An Impact becomes evidence-backed only when the professional links at least one evidence item and confirms it supports the claim; AI may suggest the link, but only the professional's confirmation changes the status. Removing the last confirmed evidence item returns the Impact to user-approved. Evidence is private by default; restricted evidence is shared through permissioned links with expiry, revocation, and an audit trail.
8. The professional previews and edits a profile (headline, summary with optional AI help, location, phone number), selects approved Impacts to publish, chooses whether to appear in employer search, and publishes. Visibility is set per profile and per Impact: private, verified employers only, or public. Only published content is public, at a stable user-controlled profile URL.
9. The professional can share a profile or Impact through Open Graph previews, the standard share action (WhatsApp, LinkedIn), QR code, or copied link; export personal data; or delete the account, with data deleted in line with the documented retention policy.

Result: Approved Impacts and selected evidence are saved, published, and discoverable according to the professional's settings. If the professional adds information or requests suggestions later, AI proposes new or updated Impacts into a suggestion queue as drafts, each showing what would change, why, and which new input prompted it as a before-and-after comparison; no change is applied without approval, and suggested changes to published Impacts apply only after approval.

Branches: If the AI finds fewer than three defensible Impacts or none, the professional sees what is supported, a clear explanation of the gap, and guided questions instead of invented content, with next steps: answer follow-up questions, add more information, or create Impacts manually. If the AI fails or is unavailable, the professional sees a clear message, can retry, and can continue with the manual workflow. Approving a material change to a published Impact preserves the prior version and its status in auditable history; an evidence-backed or verified Impact returns to user-approved until the professional reconfirms the evidence or a new verification is completed, while unrelated verified claims retain their status. AI services have no write path to the evidence-backed or verified states.

5.2 Professional requests third-party verification

Actor: Professional; supporting actor: invited verifier, who does not need a ProoveMe account. Trigger: The professional wants a specific contribution or outcome confirmed.

1. The professional invites an appropriate colleague, manager, or other person by email or link, optionally with AI-drafted text, and tracks responses. Invitations have expiry and abuse limits.
2. The verifier opens the invitation and sees only the claim being confirmed. They confirm their email and provide their name, role, relationship to the professional, and work-domain information; a work-domain match is recorded.
3. The verifier confirms, declines, or adds a comment. Mismatches are flagged for admin review.
4. A verifier confirmation plus a passing identity check moves the claim to independently verified. Admins review flagged verifications and may uphold or remove them; an admin removal returns the claim to user-approved.

Result: The claim records the verifier's response and identity information. A material change to a verified claim triggers re-review.

5.3 Organisation requests access and onboards its team

Actors: Organisation admin; supporting actors: ProoveMe moderator or super admin. Trigger: An employer or recruiter uses the employer entry page, which explains the proposition and links to the account request.

1. The organisation supplies work identity through a work email and provides its name, website, country, and registration number.
2. ProoveMe reviews the request; admins check registration details manually against public registries (automated registry lookups are optional). Admin approval is required before the organisation can access restricted profiles or contact professionals; until then the organisation sees an awaiting-approval state.
3. Once approved, the organisation admin invites team members and assigns the organisation's admin or member role.
4. Admins may suspend the organisation or revoke its verification.

Result: Approved organisation members can use employer capabilities within their organisation's access boundary.

5.4 Organisation member discovers and contacts professionals

Actor: Organisation member. Trigger: The member needs to identify talent for the organisation.

1. The member searches by experience, capabilities, professional outcomes, and location, using structured filters, keyword and semantic retrieval combined, including natural-language search. Permission and visibility filters are applied before results are ranked or shown.
2. Each result explains why it matched, based on matched Impact text, skills, and outcomes, and shows evidence status without exposing restricted files; there are no numeric fit scores, no best-candidate labels, and no automatic rejection. Results appear in a default order based on matched content and recency, presented as an ordinary sort with user-selectable sorting; the final default is agreed in design and tested for fairness.
3. The member opens a permitted candidate view showing allowed profile information, evidence status, evidence context, and uncertainty. Restricted information remains unavailable unless the organisation has the required approval and access.
4. The member shortlists suitable professionals, organised by recruitment project, and saves searches for reuse.
5. The member sends a contact request with context through the organisation's permitted workflow.

Result: The organisation maintains relevant shortlists and contact requests while professionals' visibility and evidence permissions remain enforced. A member may report a public or employer-search profile for admin review.

5.5 Professional responds to a contact request

Actor: Professional; supporting actor: verified organisation member. Trigger: A verified organisation sends a contact request with context.

1. The professional reviews the request and accepts or declines.
2. On acceptance, the contact details the professional chooses are shared with the organisation.
3. The professional can report spam and block the organisation.

Result: Contact details are shared only with the professional's consent; blocked organisations can no longer reach the professional. Reported requests go to admin handling.

5.6 Public visitor uses the product's entry routes

Actor: Public visitor. Trigger: The visitor reaches the responsive homepage or an audience-specific route.

1. The visitor sees the proposition within the first screen and a real product preview rather than stock imagery.
2. The visitor selects the route for Professionals, Employers/Recruiters, or Partners, or reviews How it works, an anonymised Impact, privacy and trust, FAQ, contact, or legal information.
3. The visitor may use the single primary sign-up call to action or submit the contact form, which sends the enquiry to a ProoveMe email address.
4. The visitor chooses whether to allow analytics and non-essential cookies through the consent banner.

Result: The visitor is directed to the appropriate audience journey or the submitted enquiry is delivered to ProoveMe.

5.7 Professional applies to a marketplace opportunity

Actor: Professional; supporting actors: organisation member, admin. Trigger: The professional searches opportunities by region, type, and work arrangement.

1. The professional opens a role detail and eligibility page showing region, type, work arrangement, eligibility, and expiry.
2. The professional applies by selecting relevant profile content.
3. The organisation receives and reviews the application, shortlists applicants, and manages application statuses; admins approve opportunities before publication.
4. The professional tracks applications and receives status updates in the dashboard and by email.
5. The organisation contacts applicants through permitted channels.

Result: The application and its status are recorded for both sides. Users can report listings; admins moderate suspicious or expired opportunities. Marketplace messaging is built, tested, and disabled in production; when enabled, conversations are text only and linked to an opportunity or application.

5.8 Partner links professionals to a programme

Actors: Partner; supporting actor: professional, admin. Trigger: An approved partner issues an invitation code or link.

1. The partner is approved through the same approval queue used for organisation verification.
2. The partner issues invitation codes or links with expiry and use limits.
3. The professional consents before being linked to the programme.
4. The partner sees a basic list of linked professionals who have consented to share; there are no public participant lists.

Result: Consented professionals are associated with the programme; referral attribution never exposes private identities.

5.9 Admin moderates, configures and audits

Actor: Admin (moderator or super admin). Trigger: A flag, approval request, or configuration need arises.

1. The admin works the approval queue for organisations and partners, and reviews flagged verifications, reported profiles, and reported listings.
2. The admin handles suspicious-access alerts and can request access to sensitive AI data or private evidence with a recorded reason.
3. The admin sets configuration: countries, locations, onboarding copy, referral prompts, and AI usage limits.
4. The admin views the audit log of recorded actions.

Result: Moderation decisions, access grants, and configuration changes are recorded and auditable.

05

Prototype three journeys: a professional sharing an Impact, a viewer arriving through a

referral link, and a verified employer requesting contact with the professional's consent

Brief Add. C

DES-

Section 10

Demonstrate the journey: CV upload, at least

three Impacts where supported, clarification,

review, approved publication; explain behaviour

with fewer than three

End-to-end

demonstration and

fallback behaviour

Sections 3.1, 5.1, 11

Section 11

6. Visuals Colors and Theme

[Design proposal; unspecified choices are defaults.]

Muse: Kenya Hara — “Quiet proof.” Premium, approachable and professional: calm authority rather than job-board density. Brand message: “Your experience tells. Your impact proves.” Promise: “Make your impact visible.”

• Light-mode palette: warm-white background #FCFCFA; surface #F2EFE9; navy text and primary #10213E at approximately 90% opacity; teal #087F78 for actions and rules only; muted #6E6A62; thin rules #DED9CF. Green #1E7A46 is reserved for confirmed verification states alone.
• Typography: Zen Kaku Gothic New Light 300 headings in sentence case with wide tracking (0.02em on the hero headline); Noto Sans body. Modular 1.5 scale: display 40/60/88/120px, body 28/20/16px, labels 13px with 0.12em tracking. Responsive scaling such as clamp() keeps headlines, wordmarks, labels, numbers, card text and controls whole inside the viewport and their container at 375px, 768px and 1280px.
• Shape and layout: square corners, 1px rules, square image frames, no shadows, no rounded cards. One centred 640px column inside wide margins; small quiet labels and numbers beside large empty fields; sections divided by thin rules.
• Imagery: one softly lit still life of a real product preview on a plain warm ground, with natural paper and stone textures. Preview imagery replaces stock imagery; no stock people.

• States and accessibility: every AI screen designs empty, loading, success, error, restricted-access and consent states. Provenance and verification use words as well as colour. Keyboard navigation, readable contrast, accessible forms and assistive-technology-compatible approve, edit and reject controls. Clear progress during analysis; heavy documents on slow networks may process in the background with a notification when ready, and the user can leave and return.
• Coverage: the system carries across public mobile hero, navigation and registration; professional step-by-step creation and preview; employer search filters and candidate cards; partner responsive read-only essentials; marketplace opportunity cards, apply flow and status — with reusable components, all screen states, responsive Figma designs and clickable prototypes. Nigeria-relevant copy and examples without limiting international users; fast-loading pages and a prominent mobile sign-up.
• Defaults (labeled): brand assets (logo, fonts, guidelines) are pending; the palette, type and shape tokens above follow the creative direction until supplied assets arrive.

Brief (Brand

direction)

Premium, approachable, professional visual direction

Colours: navy #1 021 3E, teal #087F78, warm white #FCFCFA. Green used only for confirmed

verification states.

7. Signature Design Concept

[Design proposal; unspecified choices are defaults.]

Signature concept: the proof table.

The public entry is a full-width warm-white field: a small navy wordmark top left, a thin full-width rule carrying the label “Your experience tells. Your impact proves.”, an oversized light headline in one narrow left column, and a real product-preview panel in #F2EFE9 at 55% width on the right. One teal text link sits below the headline — no blue CTA on white.

The defining preview is an Impact shown as a ruled table of Situation, Decision, Action, Outcome and Evidence rows with one teal rule. Verification appears as small square chips carrying a word and a colour, never colour alone; green marks confirmed verification only. Section openers use one small tracked label above a large empty band.

The composition recomposes accepted content only: professionals create and preview their impact, employers evaluate candidate evidence, partners read approved essentials, and marketplace users follow application status. Ongoing management is user-triggered — no change applies without explicit approval — and each Impact supports approve, edit or reject with a suggestion queue and before/after comparison. Questions and explanations stay plain-language and avoid metrics users lack.

Avoid rounded shadow cards, gradient blobs, glass panels, stock office photography and bouncy hover motion. Generous emptiness keeps long reading calm and suits slow networks.

8. Interaction Model & Motion Direction

[Design proposal; unspecified choices are defaults.]

Interaction Model: Static (direction) Motion Tempo: still Hero Dimensionality: flat

8.1 Landing Hero Motion Brief

• Focal subject: one softly lit real product-preview panel showing the ruled Impact table on a warm paper-and-stone ground.
• Input → transformation → outcome: a professional’s experience enters as accepted Impact content; the preview organizes it into Situation, Decision, Action, Outcome and Evidence; the outcome is a legible, evidence-based record whose verification state reads without colour alone.
• Motion vocabulary: composed stillness — only slow 600ms opacity fades on section entry. No parallax, hover lift, bounce or decorative movement.
• First frame: warm-white field; small navy wordmark top left; thin rule with “Your experience tells. Your impact proves.”; oversized responsive light headline left; preview panel right; one teal text link below the headline. All readable text and controls stay whole at 375px, 768px and 1280px.
• Reduced-motion state: the same fully usable static arrangement with no fades; preview, labels, controls and text complete and uncropped.

Motion never implies an automatic change: approval, edit and rejection stay explicit and user-triggered, and background processing surfaces progress and a return path.

9. Non-Functional Requirements

Feature flags for the marketplace, messaging, partner and monetisation modules, enforced on the server and

in the UI

Requirement

Source

Requirement

Source

Responsive web application, designed mobile-first. No native apps.

Brief,

A1

Three environments: development, staging and production. The marketplace is enabled in staging for

testing.

E3-B8

Fast-loading pages, accessible typography and a prominent sign-up on mobile

Evidence files are encrypted at rest

ORG-

07

Tenant isolation: an organisation's searches, shortlists, contact history and messages are

never visible to another organisation

E2

Brief Add. B

EMP-

1 3

Anti-enumeration controls, rate limits and limits on bulk export

1 4

03

AI credentials and keys are stored only on the backend and never sent to the browser

E2

INT-

04

E2, E3-AI

INT-

06

AI output can never publish content, change verification status or change permissions. These

actions are only possible through user or admin actions checked by the backend.

Brief §5A,

E3-B5

Processing and status

ID

Requirement

Source

7.​Non-functional requirements

Each item in sections 7 to 10 is written as a deliverable: something that is built, set up, documented or tested, and that can

be checked as done.

7.1​Security (SEC)

ID

Deliverable

Source

SEC-

01

Set up encryption in transit (HTTPS for all traffic) and encryption at rest for the database, file

storage and backups

E2

Brief §9,

E2

SEC-

08

Set up secure development practices: code review, dependency vulnerability scanning in the

build pipeline, and a process for fixing reported vulnerabilities

E2

SEC-

09

Write the incident-response procedure for the whole platform, covering detection, response,

communication and review

Brief §9,

E2

SEC-

1 0

Build protection so private email addresses, restricted evidence and direct file URLs cannot be

extracted through public pages, search responses, unauthorised API calls or exports

Brief

Add. C

7.2​Privacy and data protection (PRV)

ID

Deliverable

Brief §9,

Brief

1 1

Build feature-flag checks on the server, not only in the UI

Brief §9

7.2​Privacy and data protection (PRV)

ID

Deliverable

Source

PRV-

01

Write a data protection design note showing how the platform supports UK GDPR and the

Nigeria Data Protection Act 2023

Brief §9, E2

PRV-

02

Write the retention and deletion schedule and the international data-transfer safeguards, and

build the scheduled jobs that apply the retention rules

E2

Host the platform in the UK or EU. Document any other location for ProoveMe's review.

Review each data record in section 1 6.3 and store only the personal data each feature needs

Provide technical input to ProoveMe's data protection impact assessment (DPIA)

E3-AI, A1 7

7.3​Performance and connectivity (PERF)

ID

Deliverable

Source

PERF-

01

Define performance budgets (page weight, load time, API response time), with targets set in the

proposal, and check them in the build pipeline

Brief §9

7.3​Performance and connectivity (PERF)

ID

Deliverable

Source

PERF-

02

Test key journeys on mid-range Android devices and constrained networks (see TST-03)

Brief §9

PERF-

03

Brief

§1 0

7.4​Accessibility and usability (ACC)

ID

Deliverable

Source

ACC-

01

Build every screen to WCAG 2.2 AA, including keyboard navigation, readable contrast and

accessible forms. Build this into the shared components so each screen inherits it.

Brief

§8

ACC-

02

Write interface text in plain language and design screens that work on slow connections

Brief

§8

ACC-

05

Test on the supported browsers listed in A1 9

A1 9

Brief

§2

7.7​Reliability and operations (OPS)

ID

Deliverable

Source

OPS-

01

Set up automated database and file backups, and test a full restore before

launch

Brief §9

OPS-

02

Set up logging, monitoring, error tracking and alerting for all three

applications and the backend

Brief §9

OPS-

03

Write the operational incident procedures (see SEC-09) as part of the

operations runbook

Brief §9

OPS-

04

Deploy to production, with a written and tested release and rollback process

Brief §5A (New-build

clarification)

OPS-

05

Set up the development, staging and production environments, with the

marketplace enabled in staging only

E3-B8

OPS-

06

Set up an automated build and deployment pipeline that runs the tests

before each deployment

A32

Design the system to grow from about 1 00 to 1 0, 000 professional accounts without

redesign, and estimate operating costs for 1 00, 1 , 000 and 1 0, 000 accounts in the

proposal

E3-A8

ARC-

03

07

Run usability testing with representative users, lower-end mobile devices and slower

connections, and report the findings and design changes

9.​Testing, security assurance and acceptance (TST)

ID

Deliverable

Source

TST-

01

Write and run functional, integration and end-to-end tests for every module, as part

of the build pipeline (OPS-06)

Brief §1 2

TST-

02

Run accessibility testing against WCAG 2.2 AA and fix the findings

Brief §8, Add. C

TST-

03

Run performance testing on mid-range Android devices and constrained networks

against the PERF-01 budgets

Brief §9

TST-

04

Run end-to-end tests of the AI workflows: low-quality or invalid uploads, AI errors

and timeouts, retry and manual fallback, user rejection, and duplicate Impacts. AI

output quality is tested by the AI team.

Brief §5A

TST-

05

Demonstrate to ProoveMe that private emails, restricted evidence and direct file

URLs cannot be extracted (see SEC-1 0)

Brief Add. C

TST-

06

Support an independent penetration test of the entire platform: professional and

employer portals, marketplace, AI integrations (including prompt injection and

cross-user leakage), APIs, authentication, authorisation, tenant isolation, private

evidence storage, employer access and admin permissions

E2, E3-B8

E3-B8

TST-

08

Fix all critical and high-risk penetration test findings and support the independent

retest before production launch

E2, E3-B8

E2, E3-B8

TST-

09

Test the complete marketplace and messaging in staging before contractual

acceptance

Monitoring and error tracking

Observability

Independent penetration

testing firm

Security assurance

Approved or appointed by ProoveMe (A1 8)

Supported browsers are the latest two versions of Chrome, Safari, Edge and Firefox, plus Chrome on Android and

Safari on iOS.

A32

Delivery uses an automated build and deployment pipeline with automated tests.

16.4​Milestones

Our proposed milestones (A31 ) . Each milestone ends with a demonstration and UAT against its acceptance criteria

(TST-10, DEL-04). Within each milestone, data records and APIs come before screens (PLN-07).

Milestone

Some deliverables are set up in M2 and then apply to every later milestone: ACC-01 and ACC-04 (every screen is

accessible and has all its states when it is built), PERF-01 (budgets are checked on every build), OPS-02 (monitoring

covers every new feature), TST-01 (each feature adds its automated tests, which run on every build through OPS-06) and

NOT-01 (each feature adds its own emails). M7 contains only the final testing of these (TST-02, TST-03, and a full run of

TST-01 ) .

Admin report handling (ADM-05, S-61 ) also starts early, in M3, with reported profiles (PRF-10). Reports on contact

requests, listings and messages are added in M4 and M6, with the features they belong to.

Main deliverables

Acceptance criteria

(summary)

tests (TST-01 ) passes.

tests pass (TST-02, TST-03).

Accessibility and performance

Pen test critical and high

findings fixed and retested. UAT

findings fixed and retested. UAT

signed off. Production

Test unsupported figures, ambiguous

achievements, incomplete CVs, low-quality

uploads, model errors, rejection and duplicates

Evaluation set and

test plan

Explain file formats, size limits, providers,

retention, consent, fallback, human review and

prompt-injection controls

Documented in the

architecture

document and this

All AI content subject to professional review and approval

Section 8

Provider-independent architecture, no-training and retention

protections, minimisation, documented locations and

subprocessors

Sections 6 and 7

Encryption, secure storage, role-based and object-level

authorisation, tenant isolation, audit logging, incident

response

Section 6.3

Manual alternative for users who do not want AI; no training

on professional data without separate authorisation

AI-11, section 6

Independent penetration test covering AI integrations and

cross-user access

Section 12

Recommendations on acceptance criteria, follow-up limits,

processing times, failure handling and Nigerian-context CV

evaluation

Section 11

UX research and usability testing with representative users,

low-end phones and slow networks

monitoring

Fixed evaluation set, regression tests on every

prompt or model change, quality and failure

Release and

runtime

5. Safeguards

5.1 Preventing fabricated claims

•​

Every claim in a draft references a source passage or a user answer; anything else is labelled as a suggestion.

•​

5.2 Prompt injection

5.3 Data protection in AI processing

CVs and evidence are treated as untrusted input. Controls include separating instructions from document content,

structured outputs only, no tool or network access during extraction, output validation, and no model-driven actions with

side effects.

Personal-data minimisation before model calls, with exclusion rules for fields agreed with ProoveMe.

•​

Providers used only under no-training and agreed retention terms, with processing locations and subprocessors

documented.

•​

Embeddings and derived data follow the same consent, deletion and export rules as the source data.

•​

No use of professional data for model training or fine-tuning without separate written authorisation.

•​

•​

6. Data protection, privacy and compliance

6.1 Principles

6.3 Security controls that apply to AI components

The client has listed the following. The AI components must meet each of them, and platform-wide delivery sits with the

FS team.

•​

Encryption in transit and at rest, including extracted text, AI outputs, logs and embeddings.

Secure storage of CVs and evidence with malware scanning and controlled access; AI reads only through the same

controlled access path.

•​

Role-based and object-level authorisation at API and database level on every AI endpoint, so one user cannot

reach another user's CV, drafts or evidence by changing an identifier.

•​

Separation of professional, employer and administrative permissions, including for AI features and logs.

•​

Tenant and user isolation: each AI call is scoped to one user, with no shared context between users.

•​

Secure development practices, dependency and vulnerability management.

6.4 Retention and deletion

Retention periods are agreed with ProoveMe and applied consistently, including on account deletion and opt-out. The

table lists what must be decided.

Data

Handling

Decision needed from

ProoveMe

Uploaded CV file

Stored in platform storage under access control

Retention period; deletion

6.4 Retention and deletion

Retention periods are agreed with ProoveMe and applied consistently, including on account deletion and opt-out. The

table lists what must be decided.

Data

Handling

Decision needed from

ProoveMe

Extracted text

Kept only as long as needed for the user's journey

Retention period

6.4 Retention and deletion

Retention periods are agreed with ProoveMe and applied consistently, including on account deletion and opt-out. The

table lists what must be decided.

Data

Handling

Decision needed from

ProoveMe

AI drafts and

on request

suggestions

Kept with the user's account until the user deletes

them

Retention of rejected

suggestions

Prompts and model

responses in logs

Minimised, no raw personal data where possible

Whether stored, and for

how long

Embeddings for

search

Created only from published, consented content;

removed when content is hidden or deleted

Anonymised or consented data only

Written authorisation

Provider-side

retention

No-training and the shortest retention available

under the provider's terms

Acceptable provider terms

Quality, error, latency and usage metrics with minimised

logging

9. Usability, accessibility and low-bandwidth experience (AI)

The AI experience is a part of the professional journey and follows the platform's UX approach: mobile-first, English at

launch, suitable for different levels of digital literacy and connectivity, and accessible to WCAG 2.2 AA.

•​

Plain language: questions, labels and explanations avoid jargon. Provenance labels use words as well as colour.

•​

Light payloads: results are delivered in small steps, so a mid-range phone on a constrained network can use the

flow.

States: empty, loading, success, error, restricted-access and consent states are designed for every AI screen.

Usability testing of the AI journey

The client asked how journeys are validated before launch. For the AI journey we propose testing with representative

professionals at different career stages, on mid-range Android devices and throttled networks, and measuring task

completion, time to first approved Impact, edit and rejection rates, and whether users understand the provenance labels.

UX research is led by the platform design team, and the AI team provides prototypes, outputs and quality data. Results

feed back into prompts and question limits.

10. Acceptance criteria and evaluation

The criteria below are proposed starting points. Final targets are agreed after a baseline run on a representative set of

Nigerian-context CVs, as the client suggested.

Area

Measure

Proposed starting point

Fabrication

Unsupported figures or named

entities shown in drafts

Zero tolerance for figures not present

in source or user input; any case is a

defect

Fabrication

Claims reaching publication

without user approval

Zero; verified by automated and

manual tests

Detection quality

Drafts proposed where source

material adequately supports at

least three Impacts

Met on the agreed test set;

behaviour defined where fewer exist

Draft quality

Share of proposed Impacts

approved or edited rather than

rejected

Baseline measured, target agreed

after baseline

Follow-up questions

Questions asked per Impact and

per session

Proposed maximum of three per

Impact and ten per session

Injection resistance

Seeded hidden-instruction CVs and

evidence files causing any

unintended output or action

Zero successful attempts on the

agreed test suite

Isolation

Cross-user data appearing in AI

output, retrieval or search

Zero in tests, including manipulated

object references

Measure

Proposed starting point

Performance

Time to first Impact proposals for a

text-based CV

Proposed 95th percentile under 60

seconds, with progress shown;

The evaluation set covers unsupported figures, ambiguous achievements, incomplete CVs, scanned and photographed

uploads, model errors, user rejection and duplicate Impacts, as required in the brief.

10.1 Evaluation data and method

•​

Test set: anonymised CVs from the target Nigerian user base, covering different formats, career stages, informal

and non-employment experience, and scanned or photographed uploads. If real samples are not available early,

synthetic CVs are used to start and replaced as real samples arrive. Whether and when samples are shared is an

open item (section 20).

Reference answers: domain reviewers label which Impacts are defensible, and which statements are supported,

using a rubric agreed with ProoveMe.

•​

Baseline: a first run before tuning, so targets are set against measured performance and not assumed.

•​

Regression: the full set runs on every change to a prompt, model or provider, and a failed threshold blocks

release.

•​

Human review: a sample of outputs is reviewed by people on each release.

•​

Reporting: results are reported to ProoveMe at each phase gate, and form the AI acceptance report.

10.2 Test types

Test

What it covers

Functional

End-to-end journey from upload to approved publication, and each

capability in section 3

Fabrication

Unsupported figures, inflated wording, contradictory dates, thin source

material

Edge cases

Incomplete CVs, ambiguous achievements, career gaps, unusual titles,

duplicates, very short or very long documents

Document quality

Scanned, photographed, low-resolution and multi-column files,

unsupported formats

Failure handling

Model error, timeout, provider outage, partial results, retries, fallback

to manual

User behaviour

Rejection, repeated rejection, skipped questions, answers that

contradict the CV

Security

Prompt injection, cross-user leakage, manipulated object references,

permission bypass through the API

Privacy

Field removal before model calls, deletion and opt-out effects,

embedding removal

Test

What it covers

Fairness

Search results and drafts compared across the test set for unexplained

differences

Performance

Processing time on mid-range Android devices and throttled networks

Accessibility

Keyboard use, screen reader behaviour and contrast on AI screens

10. Tech Stack

Requirement

Source

Brief §9

API-first modularity without microservices

7.8​Architecture and scalability (ARC)

ID

Deliverable

Source

ARC-

01

Write the technical architecture document, including the stack and hosting choice

and the reasons for them

Brief §9

ARC-

02

Design the data model and APIs so ATS integration, advanced partner features, a

payment provider and third-party listing feeds can be added later without major

redevelopment

E3-A4, E3-A5,

E3-A6, E3-A7

11.​Third-party services

Service

Purpose

Notes

Cloud hosting (UK or EU)

Application, database and

file storage

PRV-04

11.​Third-party services

Service

Purpose

Notes

AI provider(s) and document

text extraction

AI features

Selected and costed in the AI document. Called only

from the backend (INT-01 ) .

Email delivery

Transactional emails

Malware scanning

Uploaded files

Google sign-in

Authentication

7. AI providers and architecture

7.1 Provider approach

The client prefers a provider-independent architecture. The supplier builds an abstraction layer so models can be changed

through configuration, with no change to product behaviour. At least two providers are compared on the same

The client prefers a provider-independent architecture. The supplier builds an abstraction layer so models can be changed

through configuration, with no change to product behaviour. At least two providers are compared on the same

Nigerian-context CV set before one is chosen. The options considered are managed model APIs under enterprise terms,

managed options with regional processing, and a self-hosted open-weight model as a fallback for any data class that

cannot leave a chosen region, accepting a possible trade-off in quality and in operations.

Nigerian-context CV set before one is chosen. The options considered are managed model APIs under enterprise terms,

managed options with regional processing, and a self-hosted open-weight model as a fallback for any data class that

cannot leave a chosen region, accepting a possible trade-off in quality and in operations.

Selection criteria:

•​

Extraction and drafting quality on Nigerian-context CVs, and rate of unsupported statements.

Reliability of structured output.

Latency on mobile and constrained networks.

Data terms: no training on customer data, retention options, zero-retention availability.

•​

Processing locations, subprocessors and data transfer position.

•​

Availability, rate limits, deprecation policy and ability to switch.

11. Assumptions and Constraints

1.2​Rules for planning from this document

These rules apply to anyone, or any tool, that turns this SRD into an implementation plan.

ID

Rule

PLN-

01

Use only this document as the source. Anything not in this document is out of scope unless it is added to it

first.

03

Every task names the requirement IDs it delivers. Every requirement ID in sections 6 to 1 0 is delivered by at

least one task, except the rules and conditions listed in PLN-1 3.

PLN-

1 3

Some requirements are rules or conditions, not work: they state what must not happen, a principle to follow, or

a commercial condition. Examples are EMP-05, EMP-07, MKP-1 4, MSG-07, BIL-04, BIL-05, SEO-05, SEO-06,

ARC-04, TST-07, DEL-03 and DEL-04. Do not create a task for these. Add them as acceptance checks on the

tasks they affect. DEL-03 (warranty) is planned as a support period after launch, not as a build task.

PLN-

04

Each requirement has one main task. Other tasks refer to it instead of restating it.

PLN-

05

The Impact status rules are defined once, in section 1 6.2. Tasks refer to section 1 6.2 instead of repeating the

rules.

PLN-

07

Within each milestone, build the data records and API for a feature before its screens.

PLN-

08

The deliverables in sections 7 to 1 0 are planned as tasks, not as notes on other tasks.

PLN-

09

Do not add limits, input sources, approval steps or user actions that are not stated in this document.

PLN-

1 0

Do not plan the items in section 1 2, unless ProoveMe confirms an optional item in 1 2.2.

PLN-

1 1

Follow the milestone order in section 1 6.4. Milestones may overlap only where a task's dependencies are

already complete.

PLN-

1 2

State effort in one unit (person-days). The total must match the team size and timeline stated in the plan.

Live

Brief §6, E2,

E3-B3

E2, E3-B8

E3-A4

Architecture, entitlements and admin

settings only. No live payments.

Exclusions and optional items are listed in section 12.

Brand assets and visual references provided by ProoveMe

06

Nigeria-relevant copy and examples, without limiting international users

Brief §4,

A1 6

MKT-

07

Brief §4

MKT-

08

Brief §1 0

Brief §5,

E3-B4

PRO-

01 c

Start path 3, guided questions: the professional answers a set of questions about their

experience, one step at a time. Whether the answers are sent to the AI is TBC (A33).

E3-B4, A33

01 d

Note: the platform does not claim to prevent off-platform contact entirely. (Brief Add. C)

6.10​Opportunity marketplace (MKP): built, tested and disabled in production

No sponsored listings, paid candidate ranking or payment flows

Brief §7

MKP-

1 5

Marketplace pages are not indexed until launch. JobPosting structured data is used only for

genuine published jobs after launch.

Brief §9, E2,

E3-B8

MKP-

1 7

Uses the same professional and organisation accounts, so no rebuild is needed to activate it

Disabled in production together with the marketplace

Not a general messaging platform: no group chats, no messages between professionals

and no messaging outside an opportunity or application

The data model and permissions allow advanced partner features to be added later

without major redevelopment

All users have free access at launch

A1 2

BIL-

05

No checkout, payment collection, live subscriptions or paywall without ProoveMe's

written authorisation

Brief Add. B,

E3-A5

Statuses are also shown in the user's dashboard. No SMS or push notifications.

AI touchpoints in the platform

The full-stack build provides the screens and workflows for each AI feature. The AI logic is provided by the AI team.

PRV-

03

Write the list of processing locations and subprocessors

E2

04

E3-A9–1 0

PRV-

05

E2

06

Brief §1

0, E3-B7

07

Brief

§8

ACC-

E2

03

Design for all career stages and ages, with no age-based assumptions and no required

social-media actions

SEO-

06

Rankings, AI-answer inclusion and growth are not guaranteed. This is a statement for the

proposal, not a task.

Brief

§1 0

ARC-

04

Build from scratch. No existing code, data or design assets are reused.

Brief §5A (New-build

clarification)

8.​Design deliverables (DES)

ID

Deliverable

Source

DES-

01

Complete and get ProoveMe's approval for the design phase before development of each

screen starts

Brief §8

02

TST-

07

ProoveMe approves the testing provider and may appoint it directly. This is a

condition, not a task.

Brief §5A (Quotation

and acceptance

response)

TST-

1 1

requirements)

10.​Delivery, ownership and warranty (DEL)

ID

Deliverable

Source

DEL-

01

Create the repositories, Figma files, cloud environments and third-party accounts under

ProoveMe ownership at the start of the project

Brief §1 3,

E2

DEL-

02

Deliver in the milestones listed in section 1 6.4, each with its deliverables and acceptance

criteria

Brief §1 3

11.​Third-party services

All accounts are owned by ProoveMe. Running costs are paid by ProoveMe and estimated in the proposal. (Brief §13, A21 )

Disclosed with costs (Brief §1 3)

12.​Out of scope and optional items

12.1​Not included

1.​ Native iOS or Android apps (A1 )

2.​ Languages other than English (Brief §2)

3.​ Live payment processing, checkout, invoices, live subscriptions, paywalls, sponsored listings and paid ranking (Brief §7,

E3-A5)

4.​ Messaging outside an opportunity or application, and any general social features (E3-A2)

5.​ Continuous background monitoring, automatic access to external accounts, autonomous publication and AI-awarded

verification (Brief §5A, E3-B5)

6.​ Training or fine-tuning AI models on user data (E3-B6)

7.​ Data migration, because this is a new build (Brief §5A)

8.​ Drafting legal documents and owning the DPIA (A17)

9.​ Scraping or importing third-party job listings (E3-A6, A10)

10.​ SMS and push notifications (A13)

11.​ Verifier identity checks using ID documents or external profiles (A3)

12.​ The AI logic itself: prompts, models, provider selection, prompt-injection controls, AI evaluation, AI acceptance criteria and AI

running costs. These are covered in the separate AI document (section 1.2).

12.2​Optional, quoted separately

●​ Payment provider integration and transaction handling (E3-A5)

●​ Partner landing pages, dashboards, analytics, reporting and advanced administration (E3-A4)

●​ ATS integration (E3-A7)

●​ Third-party listing feed import (E3-A6)

●​ Automated company registry lookups, for example CAC through a verification provider and the Companies House API (A2)

●​ Additional sign-in providers (E3-A11 )

●​ Ongoing security monitoring after launch (Brief Add. C)

●​ Support and maintenance after the 90-day warranty

13.​Assumptions

Each assumption is TBC until confirmed by ProoveMe or by the Master Specification.

ID

Assumption

A1

The platform is a responsive web application. No native apps are included.

A2

Third-party listings are supported in the data model and admin fields only. No feed import or ingestion is built.

A1 1

The partner foundation covers PTN-01 to PTN-07 only.

A1 2

Monetisation covers the data model, entitlements and admin settings. All users have free access at launch. No

payment provider or invoices are built.

A1 3

A1 5

A1 6

ProoveMe provides the final marketing copy, FAQ content, sample anonymised Impacts and legal text. We

provide the page structure, in-app interface text and placeholder content.

A1 7

ProoveMe's legal or data protection adviser provides the privacy policy, terms and consent wording, and owns

the DPIA. We provide technical input.

A1 8

Penetration testing fees are a third-party cost. We fix the findings and support the retest. Commercial treatment

will be confirmed in the proposal.

A1 9

A20

Documentation covers the technical architecture, API documentation, a deployment and operations runbook, and

an admin guide.

A21

A21

Third-party running costs are paid by ProoveMe through ProoveMe-owned accounts.

ID

Assumption

A25

The final fixed price is set after the Master Specification has been reviewed, and this SRD is updated at that

point.

A26

The AI team delivers the AI logic as a service or module that the backend calls. The request and response format,

error handling and data-minimisation rules are agreed between the full-stack and AI teams before development.

A31

The milestone order and content in section 1 6.4 are our proposal. Durations and effort are set in the proposal

once the team and timeline are agreed (A25).

14.​Client dependencies and open items

Item

Status

NDA and Master Product &

Pending

Contracting entity and

data-controller

arrangements

ProoveMe to confirm before contract (E3-A9–1 0)

Brand assets (logo, fonts,

guidelines)

Pending

Marketing copy, FAQs and

sample anonymised Impacts

Pending (A1 6)

Privacy policy, terms and

consent wording

Pending (A1 7)

Usability test and pilot

participants

Pending (A24)

Approval or appointment of the

penetration testing provider

Pending (TST-07)

Pricing format

Answered: one fixed price for the full scope. An indicative quote now, and the final

fixed price after the Master Specification is reviewed (E2, E3-A1 , A25). Section 1 6.5

gives the itemised breakdown.

Whether guided questions use

the AI (PRO-01 c)

Pending (A33)

Whether users can report a

profile (PRF-1 0)

Pending (A34)

PTN-06

Marketplace and messaging (disabled in production, MKP-16)

Screen

What it does

Requirements

S-

M1

Discovery and

design

DEL-01 , ARC-01 to ARC-03, PRV-01 , PRV-03, DES-

01 to DES-08, ACC-02, ACC-03, screen designs for

S-01 to S-69

Designs, prototypes, asset pack

and architecture approved by

ProoveMe

M2

Foundation

OPS-02, OPS-05, OPS-06, SEC-01 to SEC-05,

SEC-07, SEC-08, SEC-1 1 , AUTH-01 to AUTH-06,

signed off. Production

deployed.

—

Warranty

DEL-03

90 days of defect fixes after

launch

16.5​Brief releases and pricing

The brief asks for pricing by release (Brief §3, §12, Add. C). Milestones follow build order, so some milestones contain work

from more than one release. This table shows where each release is built, so each release can be priced as its own line.

Each requirement ID appears in one row only, so nothing is priced twice. The exceptions are ADM-03 and NOT-01, which

are split between rows by the part named in brackets.

All releases below are in the initial scope (section 2). ProoveMe asked for one fixed price covering the entire platform: an

indicative quote now, and the final fixed price after the Master Specification is reviewed (E2, E3-A1, A25). The rows below

are the itemised breakdown of that single price, as the brief asks for itemised components (Brief §5A). The row prices add

up to the one total, and no row is an optional extra.

Brief release

Treatment in this SRD

Requirement IDs

Built in

Discovery and

design

Priced separately (Brief

§1 2)

DES-01 to DES-08, ARC-01 to ARC-03, PRV-01 ,

PRV-03, DEL-01

M1

A: Foundation

and

professional

MVP

Core launch scope

MKT-01 to MKT-08, AUTH-01 to AUTH-06,

PRO-01 to PRO-1 5 (including PRO-01 a to

PRO-01 e), EVD-01 to EVD-08, PRF-01 to PRF-1

0, VER-01 to VER-1 0, INT-01 to INT-1 7, ADM-01

, ADM-02, ADM-04, ADM-05, ADM-07, ADM-09 to

ADM-1 3, ANL-01 to ANL-06, NOT-01

(account and verification emails), NOT-03, and

sections 7 to 1 0 except the IDs listed in the

other rows

M2, M3, M4

(verification), M5

(admin and

analytics), M7

M4

C: Partner

capability

The partner foundation is

in the initial scope

(section 2, E3-A4).

Dashboards and reports

are optional and priced

separately (section

1 2.2).

records in 1 6.3. Uses the feature flags built in A

(SEC-1 1 , ADM-07).

M2

M6

The brief asks for a

budgetary estimate only.

payment provider is

optional and priced

separately (section

1 2.2).

M5

1.3 Scope position of the client

The client wants the complete platform designed, built, tested and launched from scratch, including a full opportunity

marketplace that is developed and tested in the initial scope but disabled in production until ProoveMe gives written

authorisation. The client states this is not just architecture and database preparation. Delivery of the platform and the

marketplace sits with the FS team and is covered in the platform SOW. This document covers the AI components, and

where the platform needs AI-related behaviour it says so. Any AI use in the marketplace, for example matching or ranking,

is outside this SOW and needs separate written approval.

Section 4

Phase 1 boundary: no background monitoring,

no external account access, no autonomous

publication, no AI verification

Fixed as out of scope

SOW

Sections 5, 6, 7

Distinguish included user-triggered suggestions

from optional future automation

Stated explicitly

Section 10

2.2 Client follow-up message

Client requirement

Reference

Section 9

Complete platform and marketplace built but disabled until

authorised

Section 1.3, platform SOW

6.2 Legal framework

The obligations to be assessed are the Nigeria Data Protection Act 2023 and Nigeria Data Protection Commission

guidance, UK GDPR for UK users and employers, and other laws that apply to international users. The client has asked for

documented retention, deletion and international transfer safeguards consistent with UK and Nigerian requirements. The

supplier provides the technical data map, processing locations, provider terms summary and inputs to a data protection

impact assessment. Determining the data controller, legal bases and transfer mechanisms, and giving legal advice, remain

with ProoveMe and its legal advisers. The legal registration of ProoveMe and its controller entity are asked about in Part A.

Confirmation of scope

Evaluation sets

AI service usage depends on the number of documents analysed, size per analysis, evidence analyses and search indexing.

These usage drivers are given to the BDE for the commercial response. Any use of AI services, analytics or third-party data

These usage drivers are given to the BDE for the commercial response. Any use of AI services, analytics or third-party data

providers is disclosed, as the brief requires.

7.3 Ownership and control

AI code, prompts, configuration, evaluation sets and provider accounts are created under ProoveMe ownership and

administrative control, in line with the brief. Feature flags are enforced server-side so AI features can be switched by

configuration.

•​

Inclusive design: no assumptions based on age, and no requirement for social media use. The flow works for

graduates, early-career professionals, career changers and experienced professionals.

12. Glossary

Brief §6

ORG-

03

Brief §6, A2

04

Brief §6,

Add. B

05

Organisation types: employer, recruiter and partner

E3-A4, E3-

A6

15.​Glossary

Term

Meaning

Impact

A structured record of a professional's contribution and outcome (Situation → Decision → Action →

Outcome → Evidence)

Evidence

A file or link supporting an Impact

Verifier

A person invited by a professional to confirm a specific claim

Organisation

An employer, recruiter or partner account with one or more users

Opportunity

A marketplace listing such as a job, contract, internship, project or advisory role

Feature flag

A setting that switches a module on or off, enforced on the server and in the UI

Tenant

isolation

Keeping each user's and organisation's data inaccessible to others

DPIA

Data protection impact assessment

UAT

User acceptance testing

Status

Meaning

User-approved

Approved or written by the professional

Status

Meaning

Evidence-backed

User-approved, with at least one evidence item the professional has confirmed supports it

(A29)

Status

Meaning

Independently

verified

Confirmed by a verifier through the verification process (VER-06)

Status

Changes between statuses

From

To

Previous content and status of an Impact

PRO-09

Evidence item

EVD-01 to EVD-04,

EVD-08

Evidence share link

EVD-05

Verification

Reference

ID

Capability

What it does

Trigger

Duplicates

Area