Glossary¶

Key terms and concepts used throughout the Askalot Research Operating System.

Entities¶

Project¶

A top-level container for organizing research. Groups related Research Briefs, questionnaires, campaigns, and datasets. One project typically corresponds to one research question and carries one Research Brief through the lifecycle.

Research Brief¶

The central source of truth for a research project. Produced during ideation by the Designer agent (from source documents and natural-language objectives), refined during questionnaire design, consulted during campaign and execution, and used as the authoritative reference during analysis. The design-stage agents — Designer, Manager, Analyst — read from and write to the same Brief, so the lifecycle stages remain coherent rather than acting as disjoint tools. (The Respondent agent, which only answers surveys, deliberately has no access to the Brief.) Agents enrich the Brief by accretion: an agent must read a section before it can change it, and edits are targeted rather than wholesale, so prior-stage, human-authored, and other-agent content is preserved. The Brief is the mechanism that makes "Askalot escorts the researcher across the whole lifecycle" an architectural claim, not a marketing one.

Ideation¶

The first step of a project, before anything has been decided: the Research Brief exists but is an empty skeleton, 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 Brief carries real content, after which the Brief 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.

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.

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.

Ad-Hoc Survey¶

A survey created on the spot without campaign association. Used for testing, training, or opportunistic data collection. Not tracked in campaign statistics.

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, 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.

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.

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 selected subset of that Questionnaire's Campaigns (plus an option to include ad-hoc surveys) to exactly one linear Bronze → Silver → Gold dataset chain. 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, or for one theme discovered by open-end coding. 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.

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.

Coding Review¶

The human checkpoint between Silver derives: categories discovered in open-ended answers are accepted or rejected per column on the Bundle details page. The review state (discovered vs accepted categories, plus a pending-review flag) is readable via the API, but the accept/reject decision itself is deliberately human-only.

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 categories first, then weighted after 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 categories; then post-stratification weighting (raking) runs once over that coded case base to correct for sampling bias — coding comes before weighting so the discovered categories are available as weighting variables.

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.

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 draft the Research Brief from source documents and natural-language objectives, then write and validate questionnaires with AI assistance and Z3 SMT validation. The editor works on a working copy of your projects; 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 Brief to interpret findings against the original objectives.

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.