Equals Five PeopleOS – Detailed System Design Brief Equals Five PeopleOS | Detailed System Design Brief EQUALS FIVE Equals Five PeopleOS AI-Enabled People, Talent, Resource And Commercial Management Platform ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ | | | | :-: | :-: | | Working name | Equals Five PeopleOS | | Document purpose | Product, technical and implementation brief | | Primary users | All authorised platform users across recruitment, onboarding, delivery, management and finance | | Business owner | Equals Five Ltd | | Document status | Initial system design for validation and technical scoping | Prepared For Technical Discovery, Solution Design And Supplier Evaluation Equals Five Ltd # 1\. Executive Summary ## Purpose And Strategic Vision Equals Five requires a single AI-enabled platform to manage the complete lifecycle of its principals, specialists, candidates and wider professional network. The proposed platform, working title Equals Five PeopleOS, should become the operational system of record for every person who engages with the business, from recruitment and assessment through onboarding, client deployment, ongoing engagement, time recording, invoice reconciliation and eventual offboarding or alumni status. The objective is not simply to digitise existing administration. PeopleOS should establish a more disciplined, scalable and commercially controlled people-management capability. It should help Equals Five recruit better people, understand the depth and availability of its network, deploy resources more quickly, maintain stronger relationships with principals and give finance a clear line of sight from the original agreement through to approved time and supplier payment. At the centre of the solution should be one trusted, continuously developing person record. This should combine professional and personal information, capability and competence, sector experience, assessment evidence, availability, commercial terms, client assignments, performance feedback, relationship history and financial activity. Recruitment, onboarding, engagement, resource planning and finance should all operate from this shared source of truth. ## Business Need The current operating model relies on a mixture of LinkedIn Recruiter, ScoreApp, CVs, interview notes, emails, calendars, spreadsheets, letters of engagement, timesheets and accounting records. These tools support individual stages, but the information is fragmented and difficult to interrogate as a whole. This creates duplication, inconsistent data, manual analysis and limited management visibility. Previous applicants can be difficult to rediscover when a new requirement arises; principal skills, sector knowledge, location, availability and capacity cannot be searched easily in combination; onboarding and huddle meetings rely on manual follow-up; and client resource plans, letters of engagement, timesheets and supplier invoices are not always connected through one controlled workflow. The result is unnecessary administration, slower decision-making and increased risk of allocation or billing errors. PeopleOS should address these issues by creating a shared data model and integrated end-to-end workflows rather than a series of isolated applications. ## Proposed Solution The platform should combine the capabilities of an applicant tracking system, a candidate and principal relationship database, an AI-supported talent search engine, an onboarding and retention platform, a resource-planning system, a letter of engagement repository, a detailed timesheet tool and an invoice-reconciliation workflow. It should support five relationship groups: Core Team: Tried and tested specialists with a strong mutual commitment to Equals Five and an expectation of regular work. Flex Team: Approved specialists engaged primarily for defined projects or delivery requirements. Network: Relevant people with whom Equals Five wishes to maintain a relationship, but who may not have completed the full assessment process or have an immediate role. Candidates: People progressing through recruitment and assessment. Alumni Or Inactive Principals: People who have previously worked with Equals Five but are not currently active. The system should distinguish between lifecycle status and relationship category, with all changes time-stamped and retained as part of the audit history. ## End-To-End Operating Model The recruitment module should support vacancy creation, LinkedIn and ScoreApp data capture, AI-assisted analysis, human review, interview management, case studies, practical assessments and final categorisation. AI should summarise evidence, identify gaps and contradictions, suggest interview questions and provide an explainable recommendation. It must not make final recruitment or rejection decisions. Approved candidates should be converted into principal records without duplicate data entry. A structured ten-working-day onboarding plan should then manage the Principal Handbook, required documentation, operational and commercial briefings, system access, capability verification, availability confirmation and three standard onboarding meetings. A clear readiness status should show whether the principal can be deployed or whether mandatory actions remain incomplete. Following onboarding, the platform should support segmented communications and one-to-one huddles every four to six weeks. These meetings should capture wellbeing, workload, client relationships, support requirements, future interests, availability, risks and actions. The system should prompt relationship owners when contact is overdue and may calculate an explainable relationship-health indicator to identify potential retention concerns. For client delivery, users should be able to define a resource requirement by role, capability, sector, location, start date, duration, expected days and budget. AI should search structured data and supporting documents to recommend suitable people, explaining the match, partial matches, missing information, availability and risks. Once a principal is selected, the system should create or link a resource allocation and letter of engagement. The letter should define the client, project, scope, deliverables, dates, time commitment, rate, VAT treatment, expenses, payment terms, notice and maximum authorised value. Every amendment must create a new version so that previous commercial terms are never overwritten. Principals should record detailed time against the relevant client, project, workstream, task and letter of engagement. Entries should be validated against agreed dates, allocation, authorised value and total capacity before progressing through an approval workflow. When an invoice is received, AI may extract the details, but finance should reconcile them against the engagement, approved time, rate, VAT status, expenses and previous invoices. Any discrepancy should be explained, assigned and resolved or formally overridden before approval. ## AI Role And Governance Priority AI use cases include ScoreApp analysis, CV summarisation, skills extraction, sector classification, interview-question recommendations, natural-language talent search, principal matching, onboarding support, huddle summarisation, relationship-risk identification, capability-gap analysis, capacity forecasting, timesheet anomaly detection and invoice discrepancy detection. AI functionality should be separate from the core transactional application and use permission-aware retrieval. Outputs should identify the underlying evidence, provide an appropriate confidence indicator and remain editable by authorised users. AI must support, rather than replace, human judgement. It should not independently approve or reject candidates, change relationship categories, issue binding engagements, change rates, approve time or invoices, authorise payment or create formal performance concerns. ## Users, Security And Controls The platform will serve recruitment, leadership, operations, client leads, principals and finance. Access should therefore be controlled by role and, for sensitive information, by individual field. Principals should not see other principals’ rates or performance records; finance should receive the information required for reconciliation without automatically gaining access to confidential recruitment notes; and project leads should only see approved information relevant to their responsibilities. The solution should support single sign-on, multi-factor authentication, encryption, secure document storage, audit logging, backup and recovery, access reviews and appropriate UK data-protection controls. Residential addresses, identity documents, bank information and performance concerns should receive stronger restrictions than general professional-profile information. ## Delivery Approach A phased delivery model is recommended. Phase One should establish the master people database, recruitment workflow, ScoreApp integration, AI assessment, interview management, relationship categorisation and talent search. Phase Two should introduce the principal portal, onboarding, document acknowledgement, communications, huddles and availability management. Phase Three should add clients, projects, resource requests, capacity planning, letters of engagement, timesheets and approvals. Phase Four should introduce invoice extraction and reconciliation, accounting exports, commercial dashboards and advanced analytics. This approach reduces implementation risk, improves the underlying data before advanced AI is relied upon and allows Equals Five to realise value progressively. ## Expected Business Outcomes When fully implemented, PeopleOS should provide a complete and current view of who is in the network, what each person can deliver, where they have relevant experience, when they are available, which assignments they support, how much time has been allocated and recorded, and whether invoices are consistent with the commercial agreement. Expected benefits include faster candidate review, more consistent recruitment, stronger onboarding and retention, quicker identification of suitable resources, clearer capacity and utilisation reporting, fewer allocation conflicts, more reliable timesheet completion, faster invoice approval and reduced risk of overbilling. Over time, the information should become a strategic talent and commercial asset. Equals Five should be able to interrogate its network using natural language, identify capability gaps, forecast future resourcing needs, understand who is under-utilised or at risk of disengagement and assemble client teams with greater speed and confidence. The detailed brief that follows defines the users, data model, workflows, AI capabilities, integrations, controls, architecture, delivery phases and success criteria required to turn this vision into an implementable platform. # 2\. Business Problem Equals Five currently manages recruitment, principal information, interview feedback, onboarding, communication, project allocation and time recording across several separate systems and manual processes. These processes create a number of challenges: Candidate information is held in different locations. LinkedIn, ScoreApp, interview notes and assessment outputs are not integrated. Open-text ScoreApp responses require significant manual analysis. Interview processes rely on individuals remembering and following the correct stages. Candidate and principal records are not always complete or consistently maintained. Previous applicants and contacts are difficult to search when a new client requirement arises. Specialist experience, sector knowledge, availability and location are not easily interrogated. Onboarding activity is administered manually. Principal communications and one-to-one meetings are not consistently tracked. Project allocations, letters of engagement and time records are not held together. Accounts must manually reconcile submitted time, agreed rates, client projects and supplier invoices. Equals Five does not have a complete view of utilisation, capacity, engagement or principal relationship health. The proposed platform should address these issues through a single integrated system. # 3\. Strategic Objectives The platform should enable Equals Five to: ## 3.1 Improve Recruitment Quality Create a consistent and evidence-based recruitment process, supported by AI analysis and standardised evaluation criteria. ## 3.2 Reduce Administration Automate routine tasks such as communications, interview progression, document distribution, reminders, meeting scheduling and onboarding workflows. ## 3.3 Build A Valuable Talent Asset Create a detailed, searchable database of candidates, principals and network contacts that becomes more valuable over time. ## 3.4 Improve Talent Matching Allow users to search for people using complex combinations of skills, sectors, experience, availability, location, seniority and previous performance. ## 3.5 Strengthen Onboarding Ensure every new principal understands the Equals Five model, behaviours, commercial arrangements, processes and expectations before being deployed to a client. ## 3.6 Increase Principal Engagement And Retention Maintain regular, relevant communication and ensure principals feel connected to Equals Five even when they are not actively working on a client assignment. ## 3.7 Improve Resource Planning Provide a clear view of principal availability, allocation, capacity, utilisation and upcoming assignment end dates. ## 3.8 Improve Financial Control Connect letters of engagement, agreed rates, projects, time records, approvals and supplier payments. ## 3.9 Create Management Intelligence Provide management information covering recruitment, onboarding, network strength, utilisation, retention, principal performance and financial reconciliation. # 4\. Scope The platform should contain six core functional modules. Recruitment management Candidate and principal database AI talent search and matching Principal onboarding Principal engagement and retention Project, engagement and time management These modules should operate on a shared people and project database rather than as isolated applications. # 5\. User Groups And Permissions ## 5.1 System Administrator The system administrator should be able to: Configure user permissions Create recruitment workflows Manage assessment templates Configure interview stages Manage document templates Configure AI prompts and evaluation criteria Manage integrations Maintain reference data Access audit records Configure retention policies Resolve data-quality issues ## 5.2 Managing Director And Leadership Team Leadership users should be able to: Access all candidate and principal records Review AI evaluations and interview findings Approve principals for the core, flex or network categories Search for specialists against client requirements Review principal performance and engagement View capacity, utilisation and commercial reporting Approve exceptions and sensitive decisions ## 5.3 Head Of Recruitment And Onboarding The recruitment and onboarding lead should be able to: Create and manage vacancies Review applications Review ScoreApp results Progress candidates through recruitment stages Record interview feedback issue interview briefs and tasks manage onboarding workflows schedule onboarding meetings distribute handbooks and documents manage candidate and principal communications maintain candidate and principal records ## 5.4 Interviewers And Assessors Interviewers should have access only to the information required for the relevant assessment. They should be able to: View the interview brief View relevant candidate information Record structured feedback score agreed evaluation criteria submit interview recommendations upload notes or supporting documents Sensitive information and feedback from other interview stages may be restricted until the interviewer has submitted their own evaluation. ## 5.5 Client And Project Leads Project leads should be able to: Search for suitable principals Request resources View approved principal profiles assign principals to projects review availability and allocation approve submitted time record performance feedback request extensions or changes to an engagement ## 5.6 Finance And Accounts Users Finance users should be able to: View approved letters of engagement View agreed principal rates review approved time records reconcile time against supplier invoices identify discrepancies export payment information lock completed accounting periods view project-level cost reporting Finance users should not automatically have access to confidential recruitment notes unless separately authorised. ## 5.7 Principals And Candidates Candidates and principals should have a secure self-service portal. Depending on their status, they should be able to: Submit or update personal information Complete application questions view recruitment progress receive and acknowledge documents upload case studies and task responses book or confirm meetings complete onboarding actions provide availability update skills and experience submit time view engagement details respond to communications request support complete satisfaction or engagement surveys # 6\. Core Data Model ## 6.1 Person Record Every individual should have one master person record. Duplicate records should be detected and merged through a controlled process. The person record should include: ### Identity And Contact Information Full name Preferred name Pronouns, where voluntarily supplied Email address Telephone number Home postcode or general location LinkedIn profile Personal website or portfolio Company or trading name Country and time zone Preferred communication channel ### Professional Information Current role Career history Total years of experience Seniority level Primary discipline Secondary disciplines Specialist skills Sector experience Market experience Technology and platform experience Certifications Qualifications Languages Portfolio links Case studies CV and supporting documents ### Equals Five Status Candidate Under assessment Approved principal Core team Flex team Network On hold Inactive Alumni Rejected Do not engage A person may have both a lifecycle status and a relationship category. For example: Lifecycle status: Active Relationship category: Flex team ### Commercial Information Access to these fields should be restricted. Day rate Hourly rate Project rate Currency VAT status Company number Payment terms Bank verification status Insurance status Right-to-work or contracting documentation status Standard commercial terms Rate history ### Availability Information Current availability Available from date Days available each week Maximum preferred allocation Preferred assignment type Preferred working location Remote, hybrid or onsite preference Travel willingness Current assignments Known future commitments ### Relationship Information Relationship owner Date first engaged Source Last meaningful contact Next planned contact Engagement score Relationship risk Notes Communication preferences Interests and development goals ### Performance Information Interview scores Assessment scores Client feedback Project feedback Timeliness Communication quality Quality of work Commercial performance Reliability Re-engagement recommendation Areas of development Positive evidence and concerns Performance data should be evidence-based, time-stamped and attributed to the individual who recorded it. ## 6.2 Vacancy Or Recruitment Campaign Record Each recruitment requirement should include: Job title Discipline Seniority Employment or contracting model Core, flex or network objective Role description Job advertisement Required skills Preferred skills Sector experience Location requirements Rate or compensation range ScoreApp questionnaire Recruitment stages Interview panel Assessment criteria Target number of recruits Campaign opening and closing dates Source channels Recruitment owner Status ## 6.3 Application Record A person may apply for several different roles over time. Each application should be held separately and linked to the master person record. The application record should contain: Vacancy Application date Source CV version ScoreApp submission AI assessment Human review Recruitment stage Interview dates Interview feedback Candidate communications Documents submitted Decision Decision rationale Final relationship category ## 6.4 Project Record The project record should include: Client Project name Project reference Description Start and end date Project owner Status Approved budget Client billing model Internal cost budget Required skills Planned resources Actual resources Project documents Letters of engagement Time-recording rules Approval workflow ## 6.5 Letter Of Engagement Record Each principal assignment should have a linked letter of engagement. The record should include: Principal Client Project Engagement start and end date Scope of work Deliverables Agreed time commitment Rate Currency VAT treatment Expenses policy Notice period Payment terms Approval status Signature status Signed document Amendments Extension history Maximum authorised value # 7\. Recruitment Module ## 7.1 Vacancy Creation Authorised users should be able to create a vacancy using a structured template. AI may support the drafting of: Job descriptions LinkedIn job advertisements ScoreApp questions Interview questions Candidate evaluation criteria Case study briefs Practical assessment briefs The user must approve all AI-generated content before publication. ## 7.2 LinkedIn Integration The preferred approach should use approved integration methods, authorised exports or candidate-provided data. The system should not depend on unauthorised scraping that may breach platform terms or create an unreliable integration. The integration should support: Capturing the source vacancy Recording LinkedIn profile links Importing candidate-provided professional data Minimising manual data entry Detecting existing records Recording the original source and consent status ## 7.3 ScoreApp Integration The system should integrate with ScoreApp through an available API, webhook, structured export or automation service. The integration should import: Candidate identity Vacancy or assessment type Submission date Quantitative responses Qualitative responses ScoreApp-generated score Individual question scores Questionnaire version Completion time Any attachments Each submission should be stored as an immutable assessment record so that later changes to the ScoreApp questionnaire do not alter historical evaluations. ## 7.4 AI Assessment Of ScoreApp Responses The AI assessment should review both quantitative and qualitative responses. It should produce a structured evaluation containing: Executive summary Relevant experience Evidence of specialist expertise Sector strengths Leadership capability Strategic capability Delivery capability Communication quality Commercial awareness Evidence of measurable results Potential cultural alignment Gaps or concerns Contradictions or unclear responses Areas requiring interview exploration Suggested interview questions Overall evidence-based recommendation Confidence level The assessment should distinguish between: Facts explicitly provided by the candidate Reasonable interpretations Missing evidence AI-generated inferences The system should never present an inference as a confirmed fact. ## 7.5 Human Review The recruitment lead should be able to: Accept the AI summary Edit or annotate it disagree with particular findings add human observations record the progression decision state the reason for progression or rejection AI should not automatically reject a candidate. ## 7.6 Recruitment Workflow The default recruitment process should be configurable but initially contain the following stages: Application received ScoreApp incomplete ScoreApp completed AI assessment completed Human review First-stage interview Second-stage interview Final task or assessment Final review Approved Placed in core team, flex team or network Rejected or held for future consideration Alternative routes should be supported for network contacts who do not initially complete the full process. # 8\. Interview Management ## 8.1 First-Stage Interview The first-stage interview is normally a 30-minute informal conversation led by the Head of Recruitment and Onboarding. The system should provide a structured interview form covering: Attendance Punctuality Professionalism Engagement Communication Career overview Understanding of the Equals Five model Motivation Availability Commercial expectations Initial cultural alignment Concerns Recommendation The system should also provide the interviewer with suggested questions based on gaps or concerns identified in the ScoreApp assessment. ## 8.2 Second-Stage Interview The second-stage interview is normally led by the Managing Director or another senior leader. Candidates should receive a case study brief requiring them to demonstrate: Experience Expertise Specialist knowledge Career highlights Results achieved Strategic thinking Communication and presentation ability The system should manage: Brief distribution Submission deadlines Reminders Document uploads Presentation links Structured scoring Interview notes Final recommendation Assessment criteria should include: Relevance of experience Evidence of results Clarity of thinking Quality of presentation Depth of expertise Commercial understanding Ability to communicate with senior stakeholders Suitability for Equals Five client environments ## 8.3 Third-Stage Task Assessment The final stage is a practical assessment of approximately 90 minutes. The system should support different task types. ### Strategic And Senior Marketing Roles The candidate receives a fictional business scenario and is asked to recommend how the company should grow. Assessment should cover: Interpretation of the brief Quality of questions Strategic thinking Commercial logic Prioritisation Customer understanding Marketing judgement Practicality Measurement Presentation quality ### Specialist Delivery Roles Designers, SEO specialists, developers and other delivery specialists should receive a practical discipline-specific brief. Assessment should cover: Interpretation Technical quality Creativity Accuracy Timeliness Communication Process Quality of final output The system should record the complete assessment journey, not only the final deliverable. This includes: Questions asked Timing Communication Deadline adherence Submission version Assessor feedback Quality score Recommendation ## 8.4 Interview Scoring Each interview stage should use configurable weighted criteria. The system should calculate a stage score but also preserve qualitative feedback. A numeric score should support rather than replace human judgement. Where interviewers disagree, the system should highlight the difference and request a final decision from an authorised reviewer. # 9\. Candidate And Principal Database ## 9.1 Single Searchable Database All candidates, principals and network contacts should be maintained in one database. The database should support: Structured filtering Keyword search Semantic search Natural-language search Saved searches Talent lists Favourites Shortlists Similar-person searches Duplicate detection Data-completeness scoring ## 9.2 Natural-Language Talent Search Users should be able to enter a request such as: Find a marketing director with at least 20 years’ experience, automotive and pharmaceutical sector knowledge, demand generation expertise, ABM or ABMS experience, and who lives within 20 miles of BH23 8FG. The system should convert this request into structured criteria and return ranked matches. Each result should explain: Why the person matched Which requirements were fully met Which requirements were partially met Which information is missing Distance from the requested location Current availability Current relationship category Previous Equals Five experience Relevant performance evidence Confidence in the match Users must be able to adjust the importance of individual criteria. ## 9.3 Search Dimensions Search should support combinations of: Role Seniority Years of experience Skills Specialisms Sector experience Market experience Technology experience Location Distance from postcode Availability Day rate Relationship category Recruitment status Interview score Previous client performance Qualifications Languages Working preferences Security or compliance requirements Portfolio quality Recency of experience ## 9.4 Postcode Radius Search The platform should use a geocoding service to convert a postcode or location into approximate coordinates. Search should use general location information rather than exposing exact residential addresses. ## 9.5 Talent Pools Users should be able to create dynamic or manual talent pools such as: Automotive marketing leaders ABM specialists B2B technology writers South African delivery specialists Available marketing managers Approved designers Future Head of Marketing candidates People requiring further assessment Dynamic lists should update automatically as records change. # 10\. AI Talent Matching The AI matching service should analyse both structured information and unstructured content, including: CVs ScoreApp answers Interview notes Case studies Assessment submissions Project feedback Client feedback Skills profiles Availability Commercial terms The matching engine should produce: Overall match score Skills match Sector match seniority match availability match location match commercial match previous performance match confidence score evidence summary risks and gaps The platform should avoid giving excessive weight to confident language, writing style or presentation polish when these are not relevant to the role. Human users should always make the final selection decision. # 11\. Principal Categorisation Approved people should be assigned to one of the Equals Five relationship categories. ## 11.1 Core Team Typical characteristics: Fully assessed Tried and tested Strong performance history High level of confidence Committed relationship Priority for suitable work Expected to maintain current availability information Receives regular Equals Five communication and development support ## 11.2 Flex Team Typical characteristics: Approved to represent Equals Five Relevant specialist or delivery capability Typically engaged for specific projects May work with Equals Five less frequently Requires continued relationship management Availability may vary ## 11.3 Network Typical characteristics: Relevant professional contact May not have completed all assessments No immediate assignment requirement Potential future value Should receive appropriate communication Can be invited into a full assessment process when required ## 11.4 Category Changes Category changes should require: Reason Effective date Authorised user Supporting evidence Review date, where relevant The system should retain a complete category history. # 12\. Onboarding Module ## 12.1 Onboarding Trigger Once a candidate is approved to join the core or flex team, the platform should automatically create an onboarding plan. The plan should be based on: Relationship category Role Location Contracting model Client assignment Specialist discipline Compliance requirements ## 12.2 Principal Handbook The current Principal Handbook should be stored as a version-controlled document. The platform should: Issue the correct version Record when it was sent record when it was opened require acknowledgement retain the acknowledged version issue updated versions when required track outstanding acknowledgements ## 12.3 Onboarding Meetings The standard onboarding journey should contain three meetings. ### Meeting One Led by the Head of Recruitment and Onboarding. The meeting should cover the first section of the agreed onboarding agenda and Principal Handbook. ### Meeting Two Led by the Head of Recruitment and Onboarding. The meeting should complete the remaining operational, commercial and behavioural requirements. ### Meeting Three A 30-minute final meeting with the Managing Director or another nominated senior leader. The purpose is to: Answer final questions Reinforce the Equals Five model Clarify expectations Confirm readiness Establish the relationship Confirm any first assignment requirements Each meeting should have: A standard agenda Required preparation Attendance tracking Notes Actions Completion status Follow-up communications ## 12.4 Onboarding Checklist The checklist may include: Principal Handbook issued Handbook acknowledged Contracting information received Right-to-work or company information verified Insurance evidence received Bank details securely verified Rate agreed Communication preferences confirmed Availability confirmed Skills profile completed CV approved LinkedIn profile reviewed Case studies uploaded Teams or platform access created Email account created, where relevant Finance process explained Time-recording process explained Client confidentiality requirements accepted Onboarding meeting one completed Onboarding meeting two completed Managing Director meeting completed Ready for client deployment ## 12.5 Readiness Status The system should show a clear readiness status: Not started In progress Blocked Awaiting principal Awaiting Equals Five Ready for assignment Conditionally ready Complete A principal should not be assigned to a client where mandatory onboarding items remain incomplete unless an authorised exception is recorded. # 13\. Principal Engagement And Retention ## 13.1 Communication Programme The platform should support segmented communication with: Core principals Flex principals Network contacts New joiners Principals currently assigned Principals between assignments Specialist groups Geographic groups Communications may include: Business updates New client wins Available opportunities Training Events New processes Tool updates Handbook changes Thought leadership Community news Requests to update availability Requests to update skills or case studies ## 13.2 Communication Controls The system should record: Audience Message Sender Channel Sent date Delivery status Open or acknowledgement status, where available Responses Follow-up actions Sensitive internal messages should be restricted to the correct audience. ## 13.3 Principal Huddles The system should support short one-to-one huddle meetings, typically around 15 minutes. A huddle should capture: General wellbeing Current assignment Workload Client relationship Support required Availability Future interests Issues or risks Development requirements Actions Next contact date The platform should prompt relationship owners when a principal has not had meaningful contact within an agreed period. ## 13.4 Relationship Health The system may calculate an indicative relationship-health score using information such as: Time since last contact Communication engagement Current utilisation Availability updates Huddle sentiment Outstanding issues Assignment satisfaction Payment issues Feedback Response time The score should be explainable and should not be treated as an objective judgement of the person. ## 13.5 Retention Risks The platform should highlight potential risks such as: Core principal with no current or planned work Repeatedly cancelled huddles Reduced communication engagement Negative client experience Principal expressing dissatisfaction Delayed payments Over-allocation Under-utilisation Assignment ending without a follow-on plan Rate or commercial concerns Long period without meaningful contact Each risk should generate a recommended action for the relationship owner. # 14\. Project And Resource Management ## 14.1 Resource Request Users should be able to create a resource request containing: Client Project Required role Skills Sector experience Seniority Location Start date Duration Days per week Budget Working pattern Required deliverables Client-specific requirements The platform should search the principal database and return a recommended shortlist. ## 14.2 Allocation Once selected, a principal should be allocated to the project. The system should: Check availability conflicts calculate planned utilisation create or link a letter of engagement update the resource plan notify relevant users establish time-recording rules create assignment review dates ## 14.3 Capacity Planning The system should show: Available principals Partially allocated principals Fully allocated principals Over-allocated principals Upcoming assignment end dates Capacity by discipline Capacity by seniority Capacity by location Forecast gaps Unfilled client requirements # 15\. Time Recording ## 15.1 Timesheet Entry Principals should be able to record time against: Client Project Letter of engagement Workstream Task or activity Date Hours or days Billable status Notes Expenses, where permitted The platform should support daily or weekly submission. ## 15.2 Validation The system should validate submitted time against: Engagement dates Agreed days or hours Maximum authorised value Project status Rate Allowed workstream Duplicate entries Weekend or holiday rules Over-allocation Locked accounting periods Warnings may be overridden only by authorised users with a reason. ## 15.3 Approval Process A configurable approval process should support: Principal submits time. Project lead reviews. Disputed entries are returned with comments. Approved time becomes available to finance. Finance reconciles approved time. Accounting period is closed and locked. ## 15.4 Reminders The system should issue reminders for: Missing timesheets Draft timesheets Rejected entries Unapproved submissions Month-end deadlines Engagements approaching their authorised limit # 16\. Finance Reconciliation ## 16.1 Reconciliation Process Finance should be able to compare: Letter of engagement Agreed rate Approved time Expected principal cost Supplier invoice VAT Expenses Payment status Client billing status, where appropriate ## 16.2 Discrepancy Handling The platform should identify: Invoice exceeds approved time Incorrect rate Incorrect VAT Duplicate invoice Missing invoice Time submitted outside engagement dates Expenses without approval Letter of engagement limit exceeded Unapproved project work Each discrepancy should have: Owner Status Notes Supporting evidence Resolution Audit history ## 16.3 Accounting Exports The platform should support structured exports for the Equals Five accounting process. Exports should include: Principal or supplier Company Invoice reference Project Client Approved time Rate Net amount VAT Gross amount Payment terms Due date Approval status Cost centre Purchase order, where relevant A direct integration with the chosen accounting platform may be added once the required data flows have been confirmed. # 17\. Reporting And Dashboards ## 17.1 Recruitment Dashboard Measures should include: Open vacancies Applications by source ScoreApp completion rate Candidates by recruitment stage Time spent at each stage Interview conversion rate Offer or approval rate Recruitment cycle time Candidate withdrawal rate Assessment score distribution Recruitment workload Reasons for rejection ## 17.2 Talent Database Dashboard Measures should include: Total people Core, flex and network numbers Active and inactive records Skills coverage Sector coverage Geographic coverage Data completeness Availability Records not updated recently High-demand skill gaps ## 17.3 Onboarding Dashboard Measures should include: Principals currently onboarding Completion percentage Overdue actions Outstanding documents Outstanding acknowledgements Average onboarding duration Principals ready for assignment Blocked onboarding journeys ## 17.4 Engagement And Retention Dashboard Measures should include: Last contact Overdue huddles Principal engagement Relationship risks Principal satisfaction Core principal utilisation Assignment end dates Principals without planned work Outstanding support issues ## 17.5 Resource Dashboard Measures should include: Current allocation Future allocation Available capacity Over-allocation Unfilled client requirements Utilisation by role Utilisation by person Utilisation by client Bench time Forecast demand ## 17.6 Finance Dashboard Measures should include: Time awaiting approval Approved time awaiting invoice Invoices awaiting reconciliation Discrepancies Principal costs by client Cost against budget Engagement value used Forecast principal costs Payment readiness # 18\. AI Capabilities ## 18.1 AI Use Cases The platform should use AI for: ScoreApp response analysis CV and profile summarisation Skills extraction Sector and experience classification Interview question recommendations Interview note summarisation Talent search Principal matching Candidate comparison Onboarding support Communication drafting Huddle summarisation Relationship-risk identification Data-quality improvement Management reporting ## 18.2 AI Governance The system should include: Human approval for significant decisions Clear identification of AI-generated content Evidence linked to AI findings Confidence indicators Prompt version control Model version recording Audit logs Correction mechanisms Restricted access to sensitive data Regular bias and quality testing Data minimisation Configurable retention of AI inputs and outputs Candidate rejection, principal categorisation, rate decisions and performance action should not be made solely by AI. ## 18.3 AI Output Standards AI outputs should be: Concise Evidence-based Explainable Relevant to the role Free from unsupported assumptions Clear about missing evidence Editable by authorised users Traceable to source information # 19\. Recommended Technical Architecture ## 19.1 Application Layer A responsive web application should support desktop, tablet and mobile browser use. A native mobile application is not required for the first release, provided that time recording and principal actions work well on mobile browsers. ## 19.2 Core Services The initial platform should use a modular architecture containing: Authentication and user management People and profile service Recruitment service Assessment service Workflow and automation service Document service Search and matching service Onboarding service Communication service Project and engagement service Time-recording service Finance reconciliation service Reporting service AI orchestration service Integration service Audit service A modular monolith is likely to provide the best balance of cost, speed and maintainability for the initial release. Individual services can be separated later if volume or complexity requires it. ## 19.3 Data Storage Recommended components include: ### Relational Database A relational database such as PostgreSQL should store: People Vacancies Applications Assessments Projects Engagements Time Approvals Finance records Permissions Audit information ### Semantic Search A vector search capability, potentially using PostgreSQL with pgvector, should store representations of: CVs ScoreApp answers Interview notes Case studies Skills summaries Project feedback ### Document Storage Secure object storage should hold: CVs Portfolios Case studies Interview submissions Principal Handbooks Letters of engagement Signed documents Invoices Supporting evidence ## 19.4 Workflow Engine A configurable workflow engine should manage: Recruitment stages Interview scheduling reminders onboarding document acknowledgements huddles assignment reviews timesheet approvals finance reconciliation escalation rules Workflows should be configurable without requiring software development for every process change. ## 19.5 Integration Layer The integration layer should support APIs, webhooks and scheduled data synchronisation. Likely integrations include: LinkedIn or authorised LinkedIn data processes ScoreApp Microsoft 365 Outlook Microsoft Teams Calendars Electronic signature platform Accounting platform Document storage Identity provider Postcode and geocoding service Microsoft 365 and Teams should be prioritised where Equals Five is standardising its internal tools around that environment. # 20\. Security And Privacy The platform will hold confidential personal, commercial and performance information. It should therefore include: Role-based access control Multi-factor authentication Single sign-on Encryption in transit Encryption at rest Secure document storage Field-level restrictions for financial information Audit logging Session management Automated backups Recovery procedures Environment separation Security monitoring Vulnerability management User access reviews The platform should be designed to support Equals Five’s obligations under applicable UK data-protection requirements. This should include: Clear purpose for data collection Data minimisation Consent and communication preferences where required Subject access support Correction processes Deletion and anonymisation processes Retention schedules Restricted use of candidate information Transparent AI-assisted assessment Controlled international data transfers Supplier and processor records Exact home addresses, bank information and identity documents should receive stronger access controls than general profile information. # 21\. Non-Functional Requirements ## 21.1 Availability Target availability for the production platform should be at least 99.5%, excluding planned maintenance. ## 21.2 Performance Typical record pages should load within two seconds under normal operating conditions. Structured database searches should normally return within two seconds. Complex AI-supported searches may take longer but should normally return an initial result within ten seconds. ## 21.3 Scalability The initial platform should comfortably support: Several thousand people records Hundreds of active recruitment processes Hundreds of projects and engagements Multiple years of assessment and time-recording history Future expansion beyond Equals Five’s present headcount ## 21.4 Accessibility The user interface should target WCAG 2.2 AA accessibility standards. ## 21.5 Auditability Changes to sensitive information should record: User Date and time Previous value New value Reason, where required Related workflow ## 21.6 Data Quality The system should provide: Required fields Duplicate detection Validation rules Data-completeness scoring Expiry reminders Record-owner accountability Periodic update requests # 22\. Key Workflows ## 22.1 Candidate Recruitment Workflow Vacancy created. Job published. Candidate applies. Person record created or matched. ScoreApp issued. ScoreApp completed. Submission imported. AI assessment generated. Recruitment lead reviews. Candidate invited to first interview or declined. First interview completed. Candidate invited to second interview. Case study issued and submitted. Second interview completed. Practical task issued. Final assessment completed. Decision recorded. Candidate assigned to core, flex or network category. Onboarding initiated where appropriate. ## 22.2 New Principal Onboarding Workflow Principal approved. Relationship category assigned. Onboarding plan generated. Principal Handbook issued. Principal information requested. Required documents uploaded. First onboarding meeting completed. Second onboarding meeting completed. Managing Director meeting completed. Outstanding actions resolved. Principal marked ready for assignment. ## 22.3 Resource Assignment Workflow Resource requirement created. AI matching search performed. Shortlist reviewed. Principal availability confirmed. Commercial terms confirmed. Letter of engagement created. Approval obtained. Document signed. Principal allocated. Time recording opened. Project reviews scheduled. ## 22.4 Time And Finance Workflow Principal records time. Timesheet submitted. Project lead approves. Approved value calculated. Finance reviews. Supplier invoice received. Invoice reconciled. Discrepancies resolved. Payment authorised. Accounting period locked. # 23\. MVP Recommendation ## Phase One: People Database And Recruitment The first release should include: User and permission management Master people records Vacancy management ScoreApp integration AI assessment Recruitment pipeline Interview forms Document uploads Core, flex and network categorisation Structured and natural-language talent search Basic reporting This phase creates the core data asset upon which the remaining platform depends. ## Phase Two: Onboarding And Engagement The second release should include: Principal portal Onboarding workflows Principal Handbook distribution Document acknowledgements Meeting agendas Onboarding checklists Principal communications Huddles Relationship-health monitoring Availability updates ## Phase Three: Projects, Engagements And Time The third release should include: Client and project records Resource requests Principal matching Allocations Letters of engagement Timesheets Approval workflows Capacity reporting ## Phase Four: Finance And Advanced Intelligence The fourth release should include: Invoice reconciliation Accounting exports Commercial dashboards Utilisation forecasting Retention-risk indicators Talent-gap reporting Advanced matching Predictive resource planning # 24\. MVP Success Criteria The initial platform should be considered successful when Equals Five can: Find every candidate and principal in one system. Import and analyse ScoreApp submissions. Progress candidates through a consistent three-stage recruitment process. Produce an AI-supported candidate evaluation with evidence and human review. Categorise people as core, flex or network. Search the database using detailed natural-language requirements. Explain why each person matches a search. Maintain a complete recruitment history. Launch an onboarding workflow for an approved principal. Reduce manual administration and duplicated data entry. Produce reliable management reporting from the underlying records. Later phases should be considered successful when Equals Five can: See principal capacity and availability. Assign principals to client work. connect each assignment to an approved letter of engagement. record and approve time. reconcile time against supplier invoices. identify engagement and retention risks. forecast resource needs and principal costs. # 25\. Assumptions This design currently assumes that: Principals are usually independent contractors or specialist associates rather than permanent employees. Equals Five remains responsible for final recruitment and allocation decisions. ScoreApp continues to be used during the initial release. Microsoft 365 and Teams will be central to Equals Five communications. The platform will initially be used internally, with a limited candidate and principal portal. The recruitment and onboarding workflow may change and must therefore be configurable. The database will contain both fully assessed principals and less formally assessed network contacts. Finance reconciliation will initially support exports before deeper accounting integration is introduced. The retention process will include regular communications, short huddles, availability reviews and relationship-health monitoring. Exact process details, document templates and evaluation weightings will be confirmed during discovery. # 26\. Discovery Requirements Before development begins, the project should confirm: Current ScoreApp questionnaires and outputs Existing recruitment scoring criteria Interview forms and agendas Practical assessment briefs Principal Handbook structure Onboarding meeting agendas Current principal database and data quality Existing letters of engagement Timesheet and invoice processes Current accounting platform Microsoft 365 integration requirements Data-retention rules Principal communication programme Approval responsibilities Core, flex and network qualification criteria Required management reports AI model and hosting requirements Data migration requirements Budget and implementation timetable # 27\. Recommended Design Principle The system should be built around one central principle: Every person should have one trusted, continuously developing record that captures their relationship, experience, assessment, availability, performance, engagements and commercial history with Equals Five. Recruitment, onboarding, retention, resource management and finance should all operate from that common record. PeopleOS should not merely automate existing processes; it should create a disciplined and valuable people-management capability that helps Equals Five recruit better, deploy resources faster, strengthen principal relationships and manage commercial commitments more effectively. The next stage is to translate this brief into prioritised user stories, acceptance criteria, screen requirements and an indicative development backlog. Page