Glossary
This page is a draft. It was written against the running product on the date above and has not been through a full editorial pass, so a detail may have moved since. Tell us if a step does not match what you see.
Purpose
Plain definitions of the words you meet in the Assessor.io interface, in the order you tend to meet them. Where the interface uses more than one word for the same thing, the preferred term is the heading and the alternatives are noted underneath.
Scope
Part 1 covers product terms — things you can point at in the app. Part 2 covers documentation-programme terms, which describe how this documentation is written and maintained rather than how the product works.
Part 1 — Product terms
account
Your workspace. Everything else — campaigns, templates, members, labels, reports —
belongs to exactly one account, and nothing crosses between accounts. The account id
is the first segment of every signed-in URL (/<accountId>/dashboard/...).
Also called workspace in the interface: the sidebar header reads "workspace" and the campaign screen calls it "Back to Workspace". Older material and the database call it an organization; that term is retired.
member
A person who can sign in to an account and work in it — an administrator, a campaign manager, an auditor, a viewer. Members are managed under Team & Access. A member is not the same thing as a participant: members operate the account, participants answer assessments in it.
role
A named bundle of permissions ("Account Manager", "Campaign Manager", "Auditor") that you grant to a member. Roles are granted at a scope — the whole account, one campaign, one assessment, or one participant — so the same person can be an auditor on one campaign and nothing at all on another. Roles live under Team & Access → Member roles, and system roles are locked; you copy one rather than edit it.
policy
The building block a role is made of: a set of individual permitted actions. Roles attach policies; members are granted roles. You only need policies if the shipped roles do not fit — see Team & Access → Policies.
campaign
A single programme of assessment: who is being assessed, over what period, using which assessments. A campaign holds participants, assessments, auditor assignments, files, communications, reports and its own activity log. Campaign status is Draft, Active or Inactive, and access is either Private (invited people only) or Public (has a shareable public page).
assessment
One deployment of a template inside a campaign — the thing a participant actually opens and fills in. The campaign screen also calls these deployments. An assessment has its own name, status (Draft / Active / Completed), and, once published, a public link. Publishing an assessment is what opens it for responses.
template
The reusable question set an assessment is built from — its pages, questions and answer options, held as a SurveyJS schema. Templates live under Assessments (the page is titled "Assessment Templates"). A global template is supplied by the platform and is read-only in your account; a local template belongs to your account and can be edited, locked, cloned, exported and replaced.
Note the vocabulary collision: the sidebar item Assessments opens the template library, while an assessment is the deployment inside a campaign.
public deployment key
The short code in an assessment's public URL (/a/<KEY>). It is generated when you
publish and is what you hand to participants. Also shown as "Public Key / Link" in the
deployments table and "Public Deployment Key" in assessment settings.
statement
An action statement from the BIMe body of knowledge — a single, reusable piece of assessable content that can be bound into templates and translated independently of any one template. Statements are what the Translations → Statements workbench translates.
statement set
A named collection of statements distributed to accounts as a group, so a curated body of content can be published and versioned in one move rather than statement by statement.
participant
A person being assessed in a campaign. Participants are listed on a campaign's Participants & Roles tab. A participant has a status — Invited, Active, Suspended or Completed — and may have auditors assigned to them.
A participant does not have to be a member: someone can answer a public assessment link without ever signing in.
submission
One participant's answers to one assessment. A submission is either still a draft (in progress, autosaved) or completed. Completed submissions are what feed counts, scorecards and exports; drafts are deliberately excluded from scoring.
draft
An in-progress submission. The public assessment page autosaves answers as the participant works and shows a "Draft saved" pill; returning to the same link in the same browser restores them. A draft is tied to the browser it was started in, not to a sign-in.
auditor
A member assigned to review particular participants or assessments. Auditors work in the Auditor Workspace, where they see only their own assignments. "Supervisor" is the wording used on the participants bulk bar ("Assign Supervisor"), and it grants the same kind of scoped assignment.
review
An auditor's verdict on one answer inside one submission: a verification status (unverified, verified, modified), an optional corrected answer, an optional note, hashtags, and two switches — include it in exports, and share it with the participant. Reviews are per answer, not per submission.
assessee
The participant on the receiving end of a review. The term appears in feedback-sharing contexts to distinguish "the person being reviewed" from "the person reviewing".
scorecard
A computed result set for a campaign, produced by running a report definition over the campaign's completed submissions. Scorecards are rendered as KPI cards, bar, line, pie, heatmap or table, and are cached — the page marks each one Cached or Freshly computed.
report definition
The recipe behind a scorecard: its scope (account, campaign, assessment or participant), its report type, its aggregation rules, and its default chart. Global built-in definitions are read-only — you clone one into your account to change it. Account definitions are yours to create, edit and delete.
registration form
A public application form bound to a campaign. Applicants open it at
/register/<formId>, answer it, and their answers arrive as a registration
submission for review. Forms carry visibility switches (public, allow incognito,
allow iframe embed) and optional autonomous-triage rules.
registration submission
One application to a registration form. It has a decision state — Pending (stored as "Unverified"), Accepted, Declined, Waitlisted, or Human review required — reviewer notes, and an audit trail of who decided and when.
registration action
An "if this outcome, then do that" rule attached to a registration form — add the applicant to a campaign, attach members to them, add labels, or send a message. Actions are bound to the Accepted, Declined or Hold-like branch and run when a decision is recorded.
label
A short reusable tag with a name and an abbreviation, used to classify assessments, participants and members. Labels are grouped into label groups; each label and group is either global (supplied by the platform) or local (yours).
contact
A person in the account's lightweight CRM: a lead captured from a contact form or registration, added by hand, or pushed across from a campaign's participant list. Contacts move through the stages new → contacted → qualified → converted → lost and can be converted into a campaign participant.
activity log
The account's audit trail: who did what to which record and when, plus the notification events the system queued. Reachable at Activity Logs, and exportable as CSV.
published results
A campaign's completed results exposed at a public, read-only link (/results/<key>)
with no sign-in. You choose whether to include per-participant answers, and whether to
anonymise the people behind them.
join passcode
An account-level shared secret. Anyone signed in who goes to /join and enters the
account's join key (its slug) plus this passcode gets read-only access. Distinct
from a campaign passcode, which gates one campaign.
campaign passcode
A shared secret for ONE private campaign, set in the campaign's access settings. It
opens two doors, and they are not the same door: signed in, it joins you to the
campaign (/auth/entry?campaign=…); typed on the campaign's own public page, it lets
you answer without an account at all. A response filed that way is anonymous — the
passcode says that somebody knows a shared secret and says nothing about who they are —
so only an invitation and its personal link produce an identified response. An entry
lasts twelve hours on the browser it was typed in. Distinct from a join passcode,
which is account-level.
Part 2 — Documentation-programme terms
These describe the documentation itself, not the product. They matter if you are writing or maintaining these pages.
canonical documentation
Authoritative documentation maintained as the source of truth until explicitly replaced.
Lives under docs/ with required frontmatter.
generated documentation
Documentation produced from contracts, structured source files, or evidence bundles rather than written by hand.
ephemeral documentation
Temporary working markdown, notes, or evidence artifacts that support delivery work but are not lasting truth.
tenant admin
Umbrella persona covering account holder, admin, auditor, or similar account-side operator when shared guidance applies.
platform admin
Internal operator with cross-account or platform-level authority. Not interchangeable with tenant admin.
builder
Developer, tester, or reviewer working on the product.
agent
Autonomous or assisted software actor operating within explicit workflow scope, policy boundaries, and approval rules.