After selecting the type of talent intelligence platform and creating a shortlist, commission the pilot as a controlled decision process. Name the owner, data prerequisites, input contracts, human handoffs, measures, and stop conditions before a vendor touches employee information. The pilot should produce a reviewable stop, change, or continue decision, not a showcase.
Use this guide after category choice and comparison
“Talent intelligence platform” can describe recruiting, matching, skills, mobility, workforce planning, or employee-context products. Those categories do different work.
If the category is still unclear, use the talent intelligence tools guide to connect a business question to the right kind of input and output. If vendors are being shortlisted, use the platform comparison scorecard to test the same scenario across suppliers.
This guide starts after those choices. Its job is to commission one pilot in the contracted product version, assign operational owners, test prerequisites, record results with denominators, and hand the decision into the organisation's existing process.
Write a pilot charter before configuration
A pilot charter should fit on one page. It tells the vendor and internal team what the pilot is allowed to do and what it must not decide.
| Charter field | Entry to agree |
|---|---|
| Workforce decision | One decision due within a named period |
| Included population | Roles, locations, employment groups, and eligibility rule |
| Excluded use | Decisions or data that the pilot must not touch |
| Product boundary | Contracted module, version, region, and configuration |
| Authoritative records | Which system owns role, learning, project, interest, and decision records |
| Pilot output | The exact record a human reviewer will receive |
| Human owner | Person authorised to interpret the output and decide the next step |
| Test period | Configuration, synthetic test, live test if approved, and review dates |
| Mandatory conditions | Access, correction, provenance, deletion, and human-review requirements |
| Exit route | Data return or deletion, export format, and owner if the pilot stops |
The current UK government Sourcing Playbook is written for public contracting authorities. Its pilot principles are still a useful planning model elsewhere: define measurable objectives, scope, resources, timescales, and how results will affect the next decision before testing starts. It is guidance for its stated public-sector audience, not a rule that governs every private employer.
Assign owners and prerequisites
Do not let the vendor become the owner of the workforce decision. Assign at least these responsibilities:
- Decision owner: defines the permitted decision and signs the final record.
- Workflow owner: maps what happens before and after the platform output.
- Data owners: approve each source, definition, correction route, and expiry rule.
- Privacy and security owners: review access, processing, suppliers, retention, and incident handling.
- HR policy owner: checks how the pilot fits the organisation's employment process.
- Participant contact: explains the pilot and handles access or correction questions.
- Pilot analyst: maintains the test set, denominators, exceptions, and change log.
Before configuration, confirm that the required data exists, has an accountable owner, and is suitable for the pilot question. The O*NET database, sponsored by the US Department of Labor, can provide a shared occupation and skills vocabulary. It does not establish how work is performed in one organisation or whether an employee has demonstrated a capability.
For any AI-supported component, NIST's AI Risk Management Framework Core provides a practical structure: document the intended task and context, knowledge limits, human oversight, third-party components, test conditions, and results. NIST describes a voluntary framework; using it does not certify the vendor or the pilot.
If a live UK pilot amounts to worker monitoring, the ICO's worker-monitoring guidance calls for a defined purpose, worker information, restricted collection, justified retention, and a DPIA where the processing is likely to create high risk. The responsible privacy and legal owners must decide whether and how that guidance applies to the proposed use before employee information enters the platform.
Create an input contract for every field
An input contract prevents a familiar pilot failure: a field arrives with a confident label but nobody can explain its meaning, date, or owner.
| Contract field | Question to answer |
|---|---|
| Name and definition | What exactly does this field mean in this pilot? |
| Source and owner | Which record or person supplies it, and who can correct it? |
| Unit described | Does it describe a person, role, project, team, or period? |
| Evidence state | Is it recorded, employee-stated, manager-observed, inferred, disputed, or verified? |
| Reference date | When was it true, and when must it be reviewed? |
| Allowed use | Which pilot step may use it, and which uses are excluded? |
| Missing-data rule | Is absence shown, left unresolved, or handled another way? |
| Correction path | Where is a correction submitted, approved, and propagated? |
| Exit treatment | What is exported, returned, retained, or deleted after the pilot? |
Keep input contracts with the test record. A course-completion field may prove completion under the learning system's definition. It does not, without further evidence, prove current skill, employee interest, or suitability for an opportunity.
If the pilot informs recruitment, the UK government's responsible AI in recruitment guide recommends assurance across the system lifecycle and ongoing monitoring after deployment. Apply the organisation's existing legal and HR process to the actual jurisdiction and use. A pilot does not suspend those responsibilities.
Run a fictional test before a live pilot
Redwood Service Group is fictional. It has shortlisted a platform for an internal opportunity workflow. The business needs people who can support a six-month service redesign. The platform may organise or match profile information, but a named panel will decide whom to invite to a conversation.
The test set contains 24 synthetic profiles and six required fields per profile, giving 144 field slots. The fields are current role, relevant work example, learning record, employee-stated interest, location constraint, and source status.
The buyer deliberately includes:
- a profile with the expected job title but no current work example;
- a profile with a relevant work example outside the expected job family;
- an employee-stated interest with no evidence of the required experience;
- a disputed project attribution;
- an old learning record;
- a missing location constraint;
- two similar names with different records; and
- one synthetic person who withdraws interest during the test.
Run the agreed workflow and ask the team to inspect these behaviours:
- Does every material output retain its source, date, and evidence state?
- Does a missing field remain visible rather than causing a profile to disappear?
- Does employee-stated interest remain distinct from demonstrated experience?
- Does disputed information remain disputed until its owner resolves it?
- Does withdrawing interest change every affected view?
- Can an unauthorised role see a field or output outside its permitted purpose?
- Does the platform preserve the panel's decision as a human decision?
- Can the team produce the agreed exit record without relying on a future integration?
If the product generates a score or rank, record the source and transformation behind it, then keep it out of the human decision unless the organisation has separately established that the use is appropriate. A polished order of names is not proof that the order measures the role requirement.
Calculate separate measures with separate denominators
Suppose 110 of the 144 required field slots are populated. Of those 110 populated fields, 96 display the agreed source, date, and evidence state.
- Input coverage:
110 / 144 = 76.4%. - Traceable populated fields:
96 / 110 = 87.3%.
Do not report 96/144 as “data quality.” It combines two different questions and hides whether the defect is missing input or missing provenance.
The team then samples 20 material statements in the platform output. Eighteen trace to an allowed source, so output traceability is 18/20, or 90.0%. It submits six synthetic corrections. Five appear in every affected view before the review date, so end-to-end correction completion is 5/6, or 83.3%. The sixth updates the source profile but remains unchanged in the review packet.
That correction defect is more important than a blended score. If correction propagation is mandatory, the pilot cannot continue until the defect is fixed and the same test passes. The percentages describe this test set and version only. They are not estimates of product performance in another population or configuration.
For a later live test, keep additional denominators separate:
- people with a working access route out of everyone eligible;
- unique contributors out of unique eligible people invited;
- correction requests completed out of requests submitted;
- records accepted for human review out of records presented;
- human decisions with a named owner and date out of cases reviewed.
Participation is not capability, a completed profile is not verified skill, and a manager opening a record is not adoption of the resulting action.
Decide stop, change, or continue
Write the rules before seeing the result.
Stop when a mandatory safeguard fails, a material output cannot be traced, an unauthorised role can access information, an excluded decision enters the workflow, or the organisation cannot operate the correction or exit process responsibly.
Change and retest when the intended use remains appropriate but a field definition, mapping, permission, prompt, handoff, or configuration is correctable. Record the old and new version and rerun the same edge case.
Continue only when every mandatory condition passes, the agreed measures are reported with their denominators, named owners accept the remaining limits, and the next phase stays within the charter. Continue means the team can proceed to the next bounded phase. It does not prove that the platform improves a hiring, mobility, or workforce outcome.
Hand the pilot into the operating process
The final pack should contain the charter, product version, input contracts, synthetic test set, access record, corrections, measure calculations, defects, accepted limits, decision, and exit treatment. Record where the authoritative human decision lives after the pilot.
Do not make a future connector the condition for auditability. If the contracted environment does not write back to an existing system, define the approved manual handoff and its owner. If the workflow does integrate, test the actual contracted connection and error handling rather than a generic diagram.
Where Lontra fits
The fictional matching workflow above describes a category of talent platform. It is not a Lontra capability claim. Lontra does not provide automatic candidate matching, ranking, or a complete skills inventory.
Lontra can support a narrower input to a talent process: a focused conversation with invited employees about a defined work situation, interest, or example. The manager receives a brief with permitted context, questions, and commitments to revisit, never the employees' raw responses. People review the context, correct interpretations, and decide the action.
Living Memory can retain permitted, dated context across campaigns under roles, permissions, and human interpretation. Ask Lontra lets an authorised user explore accessible campaign context and memory through natural-language questions; its synthesis still needs review against the source, period, and scope.
If a separately verified practice needs a learning asset, Studio is a paid subscription module activated with guidance after the platform trial. It can prepare a draft from an approved source for expert and editorial review before distribution. It is not part of a matching workflow.
The Lontra trial covers one campaign with up to 30 invitations for 60 days, with no card required. Use it only when employee conversation context is the pilot job. If the requirement is candidate matching or a complete skills system, commission and test a platform designed for that category.
Frequently asked questions
What should be fixed before a talent intelligence pilot starts?
Fix the decision, population, product version, human owner, authoritative systems, input definitions, permissions, test data, review date, and stop conditions. Leave unresolved prerequisites visible rather than asking the pilot to repair them silently.
Which talent intelligence pilot measures need denominators?
Report populated fields out of required fields, traceable fields out of populated fields, traceable outputs out of outputs sampled, completed corrections out of corrections submitted, and accessible participants out of people eligible. Keep each denominator separate.
When should a talent intelligence pilot stop, change, or continue?
Stop for a failed mandatory safeguard or an output that cannot be used responsibly. Change a correctable input or workflow defect and retest it. Continue only when every mandatory condition passes and named owners accept the remaining limits.
Is Lontra an employee matching or ranking platform?
No. Lontra gathers context through conversations with invited employees and prepares a manager brief without raw responses. People review the context and decide what to do. It does not provide automatic candidate matching, ranking, or a complete skills inventory.