Skip to content

Glossary

Plain-English definitions of every term you will meet in these docs and in the Cognassist platform, so any page can link a single word instead of re-explaining it. Where the in-app label differs from the field name or the marketing name, the entry leads with the in-app label and notes the rest.

This page is a quick reference, not the deep dive. For the mental model behind the API, read Core concepts. For where each term sits in your organisation's day-to-day work, read How Cognassist is used in practice. For exact fields, types, and full enums, follow any term to the API reference.

The terms are grouped into three areas so you can scan to the one you need:

Product terms

These are the things Cognassist produces and the roles that work with them. The one idea to carry into all of them: a cognitive profile is a signal about how a learner works best, never a diagnosis and never a deficit label. Every term below leads with strengths in that spirit.

Cognitive assessment
The online assessment a learner completes in Cognassist. It measures how they take in, hold, and work with information. You invite a learner to it with the API and read the outcome back as their cognitive profile. See Send the assessment.
Cognitive profile
What the assessment produces: a strengths-first picture of how a learner works best, across nine cognitive domains that roll up into six indexes. It is a signal, not a diagnosis and not a deficit label. Read it with GET /v1/learners/{learnerId}/assessment. See Retrieve and render results.
Cognitive domain
One of the nine things the assessment measures (for example Verbal Memory, Literacy, Numeracy, Executive Function). Each domain gets a domainResult outcome. The full list and codes are in Core concepts.
Cognitive index
One of the six higher-level groupings the domains roll up into (for example Language, Memory, Speed of working). An index-level signal is a stronger, more confident signal than a single domain, which is why an index match outranks a domain match in the support-likelihood rating.
Tutor Report
The full, human-readable narrative of a learner's result, produced as a PDF. In marketing you may also see the underlying profile called a NeuroMap; in these docs and the app it is the assessment result (structured data) and its PDF report. Request the PDF with POST /v1/learners/{learnerId}/assessment/report; it arrives by webhook. See Retrieve and render results.
Reasonable adjustments
The practical, everyday changes made so a learner can work around an identified barrier (for example extra time, a reader, or a quiet space). Most awarding organisations recognise adjustments of this kind. Today you read the ones applied as selectedReasonableAdjustments on evidence records. See Core concepts.
Support plan
The set of reasonable adjustments a learner's primary tutor agrees with them after reviewing the profile. Today you read adjustment evidence through support records, not the agreed plan itself. A structured support plan as first-class API data (one entry per adjustment, with its name, implementation, goal, and impact) is planned, not live. See the Roadmap.
Evidence
In the app, the record of support that was actually delivered to a learner. In the API these are support records: list them with GET /v1/learners/{learnerId}/supportrecords, and pull the whole set in bulk with the learner export.
Support record
One API record of support delivered to a learner. It carries the adjustments applied, who delivered it, the dates, free-text reflections, and a coverage object, plus the supportType and coverageStatus enums. Values and full tables in Core concepts; schema in the API reference.
Coverage Checker
The in-app view that grades how well support is evidenced against the three I's. In the API the same information is the coverage object and coverageStatus on each support record.
The three I's
The three questions that make an adjustment defensible evidence: intent, implementation, and impact. Each carries a matching free-text reasoning field on the coverage object. Full decode in Core concepts.
Golden thread
The unbroken link from an assessed barrier, to the reasonable adjustment that answers it, to the record of support delivered, to the coverage recorded. Preserving this chain is what makes the data audit-grade evidence for your own funding and audit processes. See Core concepts.
Learner status
A three-tier, decision-support classification derived from the result, returned as learnerStatus. It is a signal to inform the people delivering learning, not a gate. Values and full table in Core concepts.
Support-likelihood rating
How confidently the result indicates a support need, returned as supportLikelihoodRating (values -1 to 6). Higher is a stronger signal, and an index match outranks a domain match. Full table in Core concepts.
Primary tutor
The one member of staff who owns a learner in Cognassist: they review the profile with the learner, agree the plan, and record evidence. Required on create as primaryTutorEmail, which must resolve to a tutor who already exists in Cognassist. See Create and manage learners.
Secondary tutor
An additional tutor assigned to a learner. A learner can have any number. Set them on create with secondaryTutorEmails, or replace the whole set later with PUT /v1/learners/{learnerId}/secondarytutors.
Tutor manager
A role that sees the learners of the tutors who report to them. Part of how assignment governs visibility: a tutor sees their assigned learners, a tutor manager sees their tutors' learners, and an admin sees everyone in the organisation.
Admin
The organisation-wide role. An admin sees every learner in the organisation and is the role that assigns tutors and views leadership dashboards. Also referred to as Client Admin for platform-configuration tasks such as connecting Microsoft Teams or single sign-on.
Insights
The in-platform, admin-only leadership dashboards covering identification, coverage, and impact across the organisation. It is not exposed as a queryable API; for cohort views in your own tools, use the bulk export.
Adaptify, Audit, Kai
Product names you may hear from Cognassist that are not part of the API surface described in these docs. If you are relying on any of them for an integration, confirm scope and availability with your Cognassist contact rather than assuming an API. See the Roadmap for the direction of travel.
Location
A planned feature that will make the distinction between sites within a single client first-class and filterable. It is not live today; your organisation is one Cognassist client with one credential set. See the Roadmap.

Regulatory and funding terms

The further-education and evidence language you will meet. The consistent framing across the docs: the data is evidence for your own processes, and any funding or cost-recovery decision is yours to make.

Cost recovery
Your organisation's own decision, under your own eligibility and quality policy, about recovering the cost of the support you provide. Cognassist supplies the evidence; Cognassist files nothing on your behalf and makes no claim for you. You use the evidence within your own funding and audit processes with the DfE. See Core concepts.
DfE
The Department for Education, the government body whose funding and audit processes the evidence supports. These docs refer to the DfE throughout; the evidence is built to stand behind your reporting to it.
Ofsted
The inspectorate. The golden thread of profile to adjustment to delivered support is the kind of traceable evidence an organisation uses to demonstrate inclusion and its impact at inspection.
Awarding organisation
The body that awards a qualification. The everyday reasonable adjustments a learner uses in teaching are recognised by most awarding organisations and can be carried into your exams process. Cognassist gives you the result and evidence to attach to that file; there is no automated push into any exams system.
Needs assessment
A separate, formal assessment an organisation may arrange for a learner. A learnerStatus of 30 Consider a needs assessment is a signal that one may be worth considering; it is a prompt for your staff, not an automatic action.
Off-programme learner
A learner who is enrolled but not currently active on a programme. The paged learner list excludes them by default; set includeOffProgrammeLearners to include them. See Create and manage learners.

Technical and API terms

Identifiers, endpoints, and the mechanics of the integration. For request and response schemas of anything here, follow the link to the API reference; this page never reproduces a full schema.

clientReference
The primary cross-system join key: the learner's id in your own system (your MIS or CRM), required on create. You own it and keep it unique. See Core concepts for how the reconcile uses it (the paged list matches on email, not clientReference).
learnerId
A Cognassist GUID returned on create. Use it on every learner-scoped call (assessment, support records, and so on) and store it. This is the Cognassist-side key you use day to day.
learnerUserId
A second Cognassist GUID, also returned on create (the underlying user id). Store it alongside learnerId; for routine learner-scoped calls, use learnerId.
email
The learner's email. Required on create and the assessment invite address. It is a natural human key, unique within your organisation, and the field the paged learner list matches on, so a match is reliable. Use it to find or confirm a learner, not as your stored join, because an email can change.
ULN (Unique Learner Number)
The learner's national identifier in the UK education system. Cognassist has no native ULN field. The closest slot is learnerUniqueReference, an optional field that is validated and unique within your organisation when supplied. Carry your ULN there if you hold one, but it is optional, so use clientReference as your primary join and carry the ULN alongside it. See Core concepts.
learnerUniqueReference
An optional secondary reference on a learner, the slot for a ULN. When supplied it is validated (letters and numbers, no spaces, a published maximum) and must be unique within your organisation. Optional, so not your primary join. It is not returned on the paged list; read it back by fetching the full learner.
UKPRN
The UK Provider Reference Number that identifies your organisation (the provider). Your API credentials are scoped to your organisation, identified by its UKPRN.
Assessment result
The structured outcome of the cognitive assessment, read with GET /v1/learners/{learnerId}/assessment. It carries the status, the per-domain domainResult values, the learnerStatus classification, and the supportLikelihoodRating. See Retrieve and render results.
status
The assessment lifecycle state, returned by label: Awaiting results · Not completed · Completed. Only Completed has a source-confirmed integer (30); read the exact integers for the other two from the LearnerAssessmentStatus enum in the API reference rather than assuming a value. See Core concepts.
domainResult
The outcome for a single cognitive domain. Values and full table in Core concepts; schema in the API reference.
Access token
The short-lived bearer token you get by exchanging your API credentials at POST /v1/auth, then send as Authorization: Bearer <token> on every call. Cache it and reuse it until it is close to expiry rather than fetching a fresh one per request. See Getting started.
OAuth 2.0 client credentials
The grant the API uses to issue an access token from a client id and secret (a server-to-server flow, no user login). It matters for low-code tools: Power Automate custom connectors do not support it, so you fetch the token with an explicit HTTP step or author the flow as an Azure Logic App. See Automate with low-code tools.
Webhook
An HTTPS endpoint you host that Cognassist calls to push an event to you, so you can react instead of polling. Manage subscriptions with POST /v1/webhooks (and the matching GET, PUT, DELETE). Preferring webhooks over tight polling is also how you stay within rate limits. See Webhooks.
System event
One of the event types a webhook can deliver (for example 100 Assessment Completed), listed with GET /v1/systemevents. The full set with ids is in Webhooks.
x-cognassist-sha256
The HMAC signature header on every webhook delivery. Verify it against the whole raw request body before you act on a payload. It is the security model for webhooks; there is no separate subscription-time URL challenge. See Verify the signature.
DataId
A GUID on every webhook payload. Cognassist retries deliveries, so the same payload can arrive more than once: treat DataId as an idempotency key, record the ones you have processed, and skip any you have already seen. See Keep in sync.
Invocation log
The delivery history for one of your webhooks, read with GET /v1/webhooks/{webhookId}/invocationlogs. Each entry carries a status: 1 Processing · 2 Successful · 3 Failed. Check it periodically and reconcile anything that shows Failed. See Keep in sync.
Learner export
The bulk pull of the golden thread, one call per request: POST /v1/learnerexports. The response only confirms the request; the full evidence payload arrives on the 700 Learner Export Completed webhook, so you must subscribe to that event first. See Export evidence and data.
Paged learner list
GET /v1/learners, which returns learners a page at a time. Each row carries a reduced projection (notably no clientReference, so reconcile on email). For the exact fields and the reconcile shape see Core concepts; for the schema and pagination parameters see the API reference. See also Create and manage learners.
totalRecords
The total count of learners returned at the top of the paged list, which lets you size the job and know when to stop paging.
Rate limit
The cap on request volume. Any endpoint can return 429 Too Many Requests; no numeric limits are published today. See Getting started for how to handle it.
Managed setup
Something Cognassist configures for you rather than a self-serve screen. Single sign-on (SSO) and SFTP are managed setups: you send the required values through the Get access route and Cognassist completes the connection.
SSO (single sign-on)
Lets people from your organisation sign in to the Cognassist web platform with your own identity provider. It is optional and does not affect the API, which authenticates with its own token. See Single sign-on.
SFTP
A managed, one-way-in only route to create learners from a scheduled CSV file. It is a limited fallback: it puts learners in but does not read data out, so it is not a complete integration and does not replace webhooks or the API. See SFTP learner uploads.
Microsoft Teams app
A convenience app that surfaces Cognassist notifications inside Microsoft Teams for your staff. It is an end-user feature, not an API surface. See Microsoft Teams.
MIS (management information system)
Your enrolment and student-records system (for example OneAdvanced ProSolution, Tribal ebs, or ESS UNIT-e). It stays your system of record; Cognassist sits alongside it and hands data back to it. See How Cognassist is used in practice.
VLE and e-portfolio
Your virtual learning environment and e-portfolio tools, where teaching happens and support is delivered day to day. Cognassist reads profiles into these tools and takes evidence back; it does not replace them.

Where to go next