Glossary¶
Key terms and concepts used throughout the Askalot Research Operating System.
Entities¶
Project¶
A top-level container for organizing research. Groups the Research Paper, questionnaires, campaigns, and datasets. One project typically corresponds to one research question and carries one Research Paper through the lifecycle.
Research Paper¶
The single record of your research, from the first idea to the final verdict — and the central source of truth for the project. It opens as its own page and prints to a PDF you can hand to a reviewer.
It grows as the work does. The Designer starts it during ideation from your source documents and objectives, and writes the goals and the instrument; the Manager records who you set out to reach and what fielding actually returned; the Analyst adds a Study per analysed dataset and the quality assessment. Each agent owns named chapters, so they enrich one document rather than acting as disjoint tools. (The Respondent agent, which only answers surveys, deliberately cannot reach the paper at all.)
Agents enrich it by accretion: an agent must read a passage before it can change it, and edits are targeted rather than wholesale, so prior-stage, human-authored, and other-agent content is preserved. It stays readable however much material you feed in, because a project is focused on one research goal — a thousand pages of regulation and a single idea narrow to the same paper.
The Research Paper is the mechanism that makes "Askalot escorts the researcher across the whole lifecycle" an architectural claim, not a marketing one.
Chapter¶
One section of the Research Paper — abstract, motivation, related work, research goals and KPIs, instrument design, population and sampling, data collection, coding and weighting, studies, data quality assessment, discussion, conclusion, appendix. Every chapter is listed from the start whether or not anything has been written into it, so the paper always shows you where the research stands rather than only what is finished.
Study¶
The chapter entry recording one analysed dataset — the Analyst's verdict on that Bundle. You choose which analyses appear in the paper and in what order: an analysis that has been run but not promoted stays out of sight without being deleted. If you later re-run the data behind a promoted Study, it is marked stale — the words stay exactly as written, and the marker tells your reader that the numbers underneath them moved.
Ideation¶
The first step of a project, before anything has been decided: the Research Paper exists with every chapter listed and none of them written, and the Designer works out the research topics and the research goal with you. Its inputs are the conversation and — if you uploaded any — the topic index of your documents. Neither documents nor a pre-existing goal are required; a study can be thought through entirely in chat. Ideation ends when the paper carries real content, after which it drives every later step.
Document topic index¶
A short synthesis of every document indexed in a project, plus a list of topics attributing each one to the file it came from. It is given to the Designer during Ideation so the agent knows what material you provided and therefore what is worth reading in depth — it is a map of the sources, not a substitute for reading them, and never the research goal. Projects with no uploaded documents simply have no topic index, which is a perfectly normal state.
Questionnaire¶
A survey definition that owns a QML version history. Contains questions, logic, and flow rules. Questionnaires are templates - they define what to ask. Its QML is stored inside Askalot rather than as a file you manage, so renaming, moving, or deleting a questionnaire never disturbs its saved versions.
Campaign¶
An active data collection effort. Links one questionnaire to a pool of respondents. Campaigns define who to survey and track progress. A campaign can additionally be set to accept walk-ins, admitting volunteers who were never drawn into its pool.
Respondent¶
A survey target - the person being surveyed. Has demographic data (age, gender, location) and contact information. Respondents access surveys via magic links without platform login.
User¶
Someone who can log in to Askalot. What a user can do is decided by their product roles: manager (campaigns, projects, pools), designer (questionnaires and QML), interviewer (conducts surveys; gated additionally by per-survey assignment), and analyst (read access to dashboards and exports). These are independent and additive — a user can hold several at once, and manager is not a superset of the others.
Two admin kinds sit on top as an attribute rather than a fifth and sixth product role: org_admin — usually an employee of the organization — manages that organization's own affairs (seats, org data, invoices, paying the bill), while tenant_admin is an Askalot operator outside the organizations who manages the organizations themselves and can, for example, make someone an org admin. Neither grants product functionality on its own.
Users are not survey targets — see Respondent.
Active organization¶
The organization a session is currently working in, as distinct from the home organization an account belongs to. Everything you can see — projects, questionnaires, campaigns, respondents, datasets — is scoped to it, and a session is only ever in one at a time. Most people belong to a single organization and never think about this; if you belong to several, or you are an Askalot operator, you move between them from the Switch Organization menu in the browser, or with switch_organization over MCP. Switching never crosses a tenant boundary — that is chosen at sign-in.
Sealed organization¶
An organization whose research record has been put beyond change. That record is its projects, questionnaires, campaigns, sampling strategies, respondent pools, respondents, surveys, datasets and Research Papers — the research itself, and everything derived from it. Reading is untouched: browsing, searching, opening the Research Paper and exporting what is already there all work as usual.
One question decides everything else you might do there: does this change the research record? Creating, editing or deleting a project, a questionnaire, a campaign or a dataset answers yes, and is refused. Trying an instrument out answers no, and so it works — you can launch a preview, share a preview link with a colleague, and open the QML editor, where the source, the graph and the live validation all work and only saving is refused. A preview never becomes data: it is not stored with your responses at all, and it clears itself once your walk is over. Publishing a campaign's open link is refused, because the volunteers who arrive through it do become data. Holding that one question lets you predict the next case instead of meeting it at the Save button.
Your own account — your password, your email address, the AI provider keys on your profile — is not part of any organization's research record. A sealed organization refuses changes to it today all the same; that is a limitation of the current control rather than something the seal is meant to cover.
A padlock badge marked Sealed sits under your organization's name in the navigation bar on every page, and anything refused explains itself where it happens. Signing in, signing out and switching organization all keep working. API tokens are the one thing closed outright: you cannot create one for a sealed organization, and one created before it was sealed stops working.
Used for the public demo organization and for keeping a departing customer's data available through its retention window.
Interviewer¶
A User with the interviewer role who facilitates surveys on behalf of respondents. Interviewers help respondents complete surveys but don't answer questions themselves.
Survey¶
An individual survey session. Links a specific respondent to a questionnaire, optionally within a campaign. Tracks progress and stores answers.
Survey Concepts¶
Direct Mode¶
Survey execution where the respondent completes the survey independently, typically via a magic link sent by email.
Interviewer-Assisted Mode (Field Interview)¶
Survey execution where an interviewer facilitates the survey on behalf of the respondent — either by phone or in person. The interviewer operates the interface and records the respondent's answers.
Campaign-Generated Survey¶
A survey created through the campaign invitation workflow. Linked to a campaign for progress tracking and reporting.
Volunteer¶
Someone who takes part in a campaign without having been drawn into its respondent pool — a person who walks up to an intercept interview, for example. A volunteer's survey belongs to that campaign like any other: same pinned questionnaire version, same dataset. It records that the respondent arrived as a volunteer rather than being sampled, which is what lets the analysis weight the two differently — a volunteer was not selected against any quota.
Ad-Hoc Survey¶
A survey a volunteer takes on a campaign that accepts walk-ins. The interviewer records the respondent's details at intake — the attributes the campaign's sampling strategy measures — and starts the interview on the spot. Name and contact details are optional.
Test Survey¶
A survey created with no campaign at all, for trying out a questionnaire or training an interviewer. It belongs to no campaign, appears in no campaign's statistics, and stays out of a dataset unless an analyst deliberately includes it.
Magic Link¶
A unique, time-limited URL that allows a respondent to access their survey without logging in. Contains encrypted survey and respondent identifiers.
QML Concepts¶
QML (Questionnaire Markup Language)¶
A YAML-based language for defining questionnaires. Specifies questions, answer options, branching logic, and validation rules.
Block¶
A logical grouping of Items within a questionnaire. Blocks organize complex questionnaires into thematic sections. Items can reference other Items across blocks. Blocks can have their own Preconditions — when set, the block precondition automatically applies to every Item within the block, in addition to any item-level preconditions.
Item¶
One unit of request to the Respondent. Item types include:
- Comment: Display-only text with no outcome (informational)
- Question: Single outcome (one answer)
- QuestionGroup: List of outcomes (multiple related answers)
- MatrixQuestion: An n × m matrix of outcomes (grid of answers)
Outcomes of an Item share the same domain constraints (the possible range of values).
Control¶
The input type for an Item: radio buttons, dropdown, checkbox, slider, text field, etc. Multi-outcome Items (QuestionGroup, MatrixQuestion) have multiple controls of the same type.
Precondition¶
A list of logical formulas that must all be satisfied to show an Item. If no Precondition is specified, it defaults to True (always show). Based on previous answers or computed values.
Postcondition¶
A list of logical formulas that must all be satisfied to accept a response for an Item. If no Postcondition is specified, it defaults to True (always accept). Used for validation.
CodeBlock¶
A Python block executed after an Item is answered (the outcome has a value) and the response has been validated by the Postcondition. Used for computed values and complex logic.
Version History¶
A questionnaire's complete, append-only record of every saved version of its QML. Each save adds a new version rather than overwriting the previous one, and nothing in the history is ever deleted. This is what lets a fielded campaign keep serving a fixed version and lets a change be undone reliably.
Pinned Version¶
The exact questionnaire version a campaign fields, fixed at the moment the questionnaire is published to that campaign. Every survey the campaign produces is served that version for its whole life — a volunteer's included — so editing the questionnaire afterward cannot change the instrument mid-interview. Publishing again after an edit re-pins the campaign to the newer version.
Campaign Concepts¶
Workload Assignment¶
Distribution of respondents among interviewers in interviewer-assisted campaigns. Each interviewer gets a subset of respondents to interview by phone or in person, and sees exactly that subset on their SirWay worklist. Until the campaign is distributed, every interviewer on it sees the whole pool.
Invitation Status¶
Tracks whether a respondent has been invited, has started, or has completed their survey.
Response Rate¶
The percentage of respondents who completed their survey out of the total invited.
Hard Bounce¶
A permanent delivery failure reported by the receiving mail server — the address does not exist. Distinct from a soft bounce, which is temporary (a full mailbox, a greylist) and does not indicate a bad address.
Suppressed Address¶
An email address Askalot has stopped sending to, across the whole platform, because it hard-bounced. Suppression is not lifted automatically; an operator clears it once the address is known to be valid again. Soft bounces and spam complaints are recorded but never suppress. See Delivery Limits and Bounced Addresses.
Discarded Send¶
A message Askalot stopped before it left the platform, because the recipient's domain can never receive mail — example.com and the other domains reserved by internet standard for testing, plus any test domains an operator has registered. Nothing is reported as an error, since these addresses belong to sample data and demonstrations rather than to people; the record of the attempt says discarded rather than sent. Distinct from a Suppressed Address, which is a real mailbox that has proven dead.
Sampling Concepts¶
Respondent Pool¶
A collection of respondents selected for a specific campaign. Pools are typically generated from a Sampling Strategy to match target demographic distributions. Unlike strategies, pools are not meant for reuse—respondents who have participated in research are generally not selected again to respect their time and avoid survey fatigue.
Sampling Strategy¶
A reusable configuration that defines target demographic distributions for respondent selection. Specifies stratification factors, target sample size, and selection algorithm. The same strategy can generate fresh pools for different campaigns, each time selecting new respondents who match the demographic criteria.
Stratification Factor¶
A dimension of a Sampling Strategy with target proportions. Usually a respondent attribute — age, gender, location, or any custom attribute — for example a gender factor targeting 48% male, 50% female, 2% other. A strategy produced by Advancing a Strategy also carries outcome factors, whose values come from survey response columns; those grade a fielded sample and cannot be sampled on.
Oversample Factor¶
A multiplier applied to target sample size to compensate for expected non-response. An oversample factor of 1.2 means selecting 20% more respondents than the target.
Selection Algorithm¶
The method used to select respondents from the pool. Options include:
- Greedy: Selects respondents that best improve demographic balance at each step
- Random Constrained: Randomly selects while respecting demographic constraints
Quality Metric¶
A measure of how well the sample matches target demographic distributions:
- RMSE: Root Mean Square Error of proportion deviations
- MAE: Mean Absolute Error of proportion deviations
- Chi-Square: Statistical test for distribution fit
- Max Deviation: Largest single proportion deviation
Data Analysis Concepts¶
Bundle¶
A named binding of one Project, one Questionnaire, and a non-empty selected subset of that Questionnaire's Campaigns to exactly one linear Bronze → Silver → Gold dataset chain. Whether Volunteers stay in the Silver analysis base is a separate per-Bundle choice; previews are not a choice at all, because a preview is not a response. Balansor's home page is a pipeline board of Bundle cards — every dataset operation (extract, derive, refine, export, check quality) is scoped to a Bundle. A Bundle owns at most one dataset per stage; comparing an alternative weighting or refinement means cloning the Bundle, not branching within it.
Representativeness¶
The measurement layer over sampling: four readings of how far a sample sits from the research design it was drawn for, taken at each transition from Strategy to weighted dataset. Strategy → Pool, Strategy → Actual and Strategy → Weighted share the Bundle's Current Strategy as their referent and therefore sit on one scale — the last two differ by exactly what weighting recovered. Pool → Actual is Pool-referenced instead, isolating what fielding itself contributed. Because no respondent is ever discarded to balance a distribution, the price of recovery is variance, so design effect and effective sample size are read beside the four rather than beneath them.
Measurement base / Analysis base¶
The two populations behind a Bundle's numbers. The measurement base is everything fielding returned — the Bronze data — and it is what the fielding readings count. The analysis base is the subset passing the Bundle's completeness threshold, applied when Silver derives from Bronze, so changing the threshold re-derives Silver without disturbing Bronze. A Survey's completeness is its answered items over the items it actually reached, so skip logic never reads as absence.
Completeness threshold¶
The per-Bundle cutoff (default 50%, expressed as a fraction) that defines the analysis base. Because it is nonresponse the operator introduced rather than nonresponse the field produced, the set it removes is profiled against the analysis base on the Strategy's own factors — a demographically skewed cut is visible rather than silent. When nothing was excluded, that is reported as such, not as a divergence of zero.
Current Strategy¶
The Sampling Strategy assigned to a Bundle as the referent every Strategy-referenced measure grades against — Strategy → Pool, Strategy → Actual and Strategy → Weighted alike, which is what puts them on one scale. Re-assignable at any time from the Bundle Overview page or via the API, and a reassignment recomputes all three; without one, those measures honestly report "no strategy" instead of a score.
Calibration Targets¶
The weighting instruction of a Bundle: a per-Bundle, freely editable list of factors, each naming a dataset column and the target proportions its values should reach. This is what raking actually weights to. It is deliberately not the yardstick the weighted result is graded against — grading a weighting against its own aim would say it hit that aim, not that the sample resembles the design — so a Calibration Targets set that drifts from the Current Strategy shows up as distance from that Strategy. Seeded once from the Current Strategy's factors the first time the Silver stage is opened, and independent of it from then on. A target category must be the value the column stores (an answer code, or 0/1 for an option column), not its caption; a factor whose categories match nothing in its column fails the derive rather than being silently ignored.
Recovery¶
How much distance from the research design weighting closed, measured in composite-error units over the factors graded on both the fielded and the weighted side. Reported in error rather than as a percentage change in the quality score, so equal improvements at different starting points produce equal figures and two Bundles are comparable. When the two sides share no commonly graded factor, it is reported as not computable rather than as zero.
Option Indicator¶
A yes/no column produced for one option of a multi-select question. Multi-select answers are stored as the combination a respondent selected, which cannot be weighted or cross-tabulated directly — the per-option columns are the analysable form. Empty rather than "no" when the respondent skipped the question. (Open-end coding does not produce these; see Coded Dimension.)
Advancing a Strategy¶
Cloning a Sampling Strategy and appending reality-grounded outcome factors — factors built from actual response columns benchmarked against external data (e.g. a party-preference question against election results). The original strategy is never edited, so pools it generated keep their historical reference; the clone can then be assigned as a Bundle's Current Strategy. An advanced strategy grades a fielded sample and cannot generate a pool — its factors describe answers that do not exist until fielding is done.
Coded Dimension¶
One axis an open-ended question's answers vary on, and the unit open-end coding produces. Each dimension you keep becomes exactly one categorical column carrying one category per respondent — the same shape a dropdown question produces. A question that varies on two things at once (what the answer is about, and how the respondent feels about it) is two dimensions and two columns. Its identity survives renaming: the column name is fixed when the dimension is first proposed, so a weighting target naming it stays valid.
Unclassified¶
The category reserved in every Coded Dimension for an answer that was given and matched none of that dimension's categories. It is a residue, not a group of people — its size measures how far the codebook reached — and it is distinct from an unanswered item, which carries no category at all. It is weightable like any other category, and a Calibration Target on a dimension must supply a share for it.
Dimension Review¶
The human checkpoint between Silver derives: proposed dimensions are read with their categories, per-category counts and example answers, then renamed, re-cut and selected on the Bundle's Silver page. Which dimensions become columns is deliberately human-only — the review state (proposals, categories, selection, and which questions are still awaiting review) is readable via the API, but there is no tool that can decide it.
Medallion Architecture¶
A data processing pattern with three stages of increasing refinement, owned by a Bundle:
- Bronze: Raw survey responses extracted from the Bundle's campaigns — the measurement base, which can include partly-finished and engine-flagged Surveys when the Bundle admits them
- Silver: Open-ended responses coded into labelled categorical columns first, then weighted by post-stratification
- Gold: Final refined dataset ready for export and analysis
Bronze Dataset¶
The first stage of a Bundle's chain, and its measurement base. Contains raw survey responses with respondent demographics but no statistical adjustments. Created by extracting surveys from the Bundle's chosen campaigns — completed ones always, plus partly-finished and engine-flagged ones when the Bundle's measurement-base toggles admit them.
Silver Dataset¶
The second stage of a Bundle's chain, and its analysis base. Surveys below the Bundle's completeness threshold are excluded first; open-ended text in what remains is coded into one column per selected Coded Dimension; then post-stratification weighting (raking) runs once over that coded case base to correct for sampling bias — coding comes before weighting so a coded dimension is available as a weighting variable in the same derive.
Gold Dataset¶
The final stage of a Bundle's chain. Contains refined data ready for export. May include field transformations (renaming, reordering, filtering) and computed fields. Created from the Bundle's Silver.
Raking (Post-Stratification Weighting)¶
An iterative proportional fitting algorithm that calculates respondent weights to align sample demographics with target population distributions. Corrects sampling bias when actual response rates differ from targets. Runs once, on the coded case base, as part of deriving a Bundle's Silver.
Respondent Weight¶
A multiplier assigned to each response during raking. Under-represented demographics receive weights > 1.0; over-represented demographics receive weights < 1.0. Applied during statistical analysis.
Normalized Entropy¶
Answer diversity for categorical questions (0 = all identical, 1 = uniform). See Quality Metrics Reference.
Straightlining¶
Identical-answer pattern across all sub-items in a question group, indicating inattentive responding. See Quality Metrics Reference.
Acquiescence Bias¶
Systematic tendency to agree with Likert statements regardless of content (50% = no bias, >60% = concern). See Quality Metrics Reference.
Cronbach's Alpha¶
Internal consistency for question groups with 3+ sub-items (>0.8 good, <0.6 poor). See Quality Metrics Reference.
Speeder¶
A respondent whose answering time falls below ⅓ of the cohort median. See Quality Metrics Reference.
Answering Time¶
The sum of the time each question was on screen during a survey, measured per question rather than as the gap between when the survey was created and when it was submitted — so an interruption or a late start is not counted as thinking time. See Speeder Detection.
Degraded Survey¶
A survey whose run recorded a problem the platform worked around rather than failing on — unevaluatable questionnaire logic, a refused prefilled value, or a repeated section asked for an undeclared subject. Graded critical, degraded, or informational by the consequence for the data; critical surveys are excluded from dataset extraction. See Degraded Surveys.
Block Visit¶
One contiguous stretch of a survey spent inside a single block — one pass of a repeated section, or one entry into a block the respondent later returns to. The survey detail page is organised as one section per block visit. See Reviewing an Individual Survey.
Baseball Rule¶
Multi-flag exclusion method: respondents with 3+ quality flags (speeder + straightliner + high non-response) are recommended for exclusion. See Quality Metrics Reference.
Completion Rate¶
Proportion of surveys reaching "completed" status in a campaign. See Quality Metrics Reference.
Design Effect¶
Variance inflation from unequal weighting: DEFF = 1 + CV^2 of weights (Kish, 1965). See Quality Metrics Reference.
Effective Sample Size¶
Equivalent unweighted sample size: n_eff = n / DEFF. See Quality Metrics Reference.
AI-Assisted Features¶
Campaign Wizard¶
A multi-step guided interface for creating campaigns. Walks users through project selection, questionnaire upload, sampling strategy, pool generation, and campaign launch with recommendations at each step.
Chat Interface¶
A conversational AI interface for campaign operations. Allows natural language commands like "create a campaign for customer satisfaction research" and executes operations through MCP tools.
Persona Profile¶
A demographic and behavioral template used for synthetic response generation. Defines characteristics like age range, income level, and response style. Examples: "Young Professional", "Family-Oriented", "Retired Senior".
Synthetic Response Generation¶
AI-powered simulation of survey responses based on persona profiles. Used for testing data analysis pipelines, validating questionnaire logic, and generating realistic test data.
MCP Tools¶
Model Context Protocol tools that expose platform operations to AI assistants. Enable programmatic access to create projects, manage campaigns, complete surveys, and analyze data through a standardized interface.
Toolset¶
A named group of MCP tools covering one area of the research workflow — sampling, fielding, analysis, and six more. A connection can name the toolsets it wants in its URL so it sees only those tools. It narrows what is in front of an assistant, never what it is allowed to do: permission stays with your subscription tier, your role, and project ownership. See MCP Integration.
Chain Tool¶
An MCP tool that runs a whole sequence of other tools in one call — preparing a campaign for fielding, simulating its responses, or running a Bundle's Bronze → Silver → Gold pipeline. Each step is the same tool an assistant would call by hand, so the same records and audit trail result. A chain checks entitlement for every step before building anything, and if it stops partway it names the step it stopped at and leaves what earlier steps built in place.
Local Models¶
The platform-hosted models that handle document embedding and, optionally, cross-encoder re-ranking of retrieved passages for the knowledge-graph retriever — kept on-platform (rather than a cloud provider) so your indexed documents' vectors never leave. To stay quiet when idle they sleep between requests and wake on first use, so a request after an idle gap takes a few extra seconds; a "Local models" indicator in the navigation bar and code editor shows whether they are ready, waking, or asleep. Distinct from the reasoning provider (Claude via Anthropic or AWS Bedrock) that powers the higher-order AI agents and the query-time keyword extraction the knowledge-graph retriever uses.
Platform Components¶
SirWay¶
The survey execution platform. Respondents and interviewers use SirWay to complete surveys.
Targetor¶
The campaign management platform. Managers use Targetor to create campaigns, import respondents, and track progress.
Armiger¶
The ideation and questionnaire design environment. Designers use Armiger to start the Research Paper from source documents and natural-language objectives, then write and validate questionnaires with AI assistance and Z3 SMT validation. You pick a project before the editor opens, and an editing session works on that one project for as long as it lasts — its questionnaires, its uploaded documents, its Research Paper, and nothing else. The editor shows you a working copy; every save you make is folded back into the questionnaire's version history automatically.
Balansor¶
The data quality analysis platform. Analysts use Balansor's pipeline board to build Bundles, code open-ended responses and apply post-stratification weighting, score response quality (straightlining, speeder, Cronbach's α), measure representativeness, and export defensible datasets. The Analyst agent reads the Research Paper to interpret findings against the original objectives, and writes its verdict back into it as a Study.
Portor¶
The API gateway and MCP server. Provides REST endpoints and Model Context Protocol tools for programmatic access to all platform operations. Powers the AI Chat Interface.
Roundtable¶
The administration platform. Manages users, organizations, and platform settings. Hosts the Campaign Wizard and Chat Interface for AI-assisted operations.