The Architecture of MR Software: Why the Stack Shapes the Research

Most comparisons between OAIRA and traditional MR software focus on outputs — speed, cost, depth. But the more interesting difference is upstream: the architecture.

Software architecture isn't neutral. The data models you choose, the layers you build, the way you represent a "respondent" or a "result" — these decisions encode assumptions about what research is for. And the dominant architecture in MR software encodes a set of assumptions that are now about 30 years old.

How Traditional MR Software Is Built

Most enterprise MR platforms — SurveyMonkey, Qualtrics, Forsta, Confirmit — share a recognisable architecture. It was designed for the web era of the late 1990s and early 2000s and has been extended incrementally ever since.

The core data model looks like this:

Survey
  └── Questions []
        └── Responses []
              └── Respondent (anonymous ID)

The respondent is an afterthought — a row identifier that answers are grouped by. The question is the primary entity. Analysis is a reporting layer bolted on top: pivot tables, filter rules, cross-tab configurations.

AI, when it appears, is a post-hoc layer: sentiment tagging on open-ended responses, auto-generated summaries, chatbot interfaces for exploring charts. It doesn't change the underlying model. The data was never designed to be reasoned about by a language model.

How OAIRA Is Built

OAIRA's core data model starts from a different root:

ResearchStudy
  ├── brief (researchQuestion, objectives, hypotheses, targetAudience)
  ├── context (currentStateAudit, researchStrategy)
  ├── checklist (12 typed decision gates)
  ├── methodology (typed: JTBD | GapAnalysis | Journey | ...)
  └── assets []
        ├── Survey (adaptive, methodology-aware)
        ├── PersonaPool (richly modeled respondents)
        ├── Simulation (1,000 synthetic agents)
        └── DeepResearch (autonomous research pipeline)

The respondent is a first-class entity with a PersonaTraitVector — 8 quantified dimensions (expertise, satisfaction, loyalty, risk tolerance, optimism, and more) derived from their profile before any question is asked.

The methodology is a typed state machine. Every question knows what it is for — its analysisHint, its pairingInfo, its methodologyContext — so analysis isn't a reporting layer. It's a computation that already knows how to interpret the data it receives.

Structural Comparison

A Practical Example: Prioritising a B2B Product Roadmap

Let's make this concrete. A product team at a B2B SaaS company wants to answer one question:

Which unmet customer needs should we prioritise in Q3?

Here is how each architecture handles it, step by step.

Traditional MR Platform — Step by Step

Step 1: Write questions manually. A researcher opens the survey builder and writes rating questions for each potential feature or outcome area. There is no framework guiding this — it depends entirely on the researcher's experience with Jobs-to-be-Done or Gap Analysis. Most teams skip the framework and write questions that feel relevant.

Step 2: Recruit a panel. The team either uses the platform's built-in panel (broad, often weakly matched to the ICP) or pastes a list of customer emails. There is no respondent modeling — each person is a future row ID.

Step 3: Run fieldwork. The survey goes live. They wait 2–3 weeks for enough responses. There is no pre-validation — if the questions were flawed, they won't know until the data comes back thin.

Step 4: Export and analyse. A data analyst exports to Excel or SPSS. They build pivot tables. They manually compute importance vs. satisfaction gaps. If the methodology was JTBD, they apply Ulwick's opportunity formula by hand — if they know it exists.

Step 5: Write a report. A consultant or senior researcher synthesises findings into a slide deck. This takes 1–2 weeks. The deck is delivered. It is often archived within a month.

Total time: 4–8 weeks. Cost: $15,000–$60,000. Output: a static deck.

OAIRA — Step by Step

Step 1: Open a Research Study and set the brief. The researcher describes the research question. The Research Designer agent reads the brief, audits the current state of the market, and recommends a methodology. For roadmap prioritisation it recommends Gap Analysis or JTBD. The study checklist — 12 typed decision gates — tracks what has and hasn't been decided.

const CHECKLIST_ITEMS = [
  { id: 'context_established',   required: true,  autoCheckable: true  },
  { id: 'research_question',     required: true,  autoCheckable: false },
  { id: 'methodology',           required: true,  autoCheckable: true  },
  { id: 'validation_simulation', required: false, autoCheckable: true  },
  { id: 'questions_reviewed',    required: true,  autoCheckable: false },
  // ... 7 more
];

Step 2: Select JTBD methodology. The instrument is generated. The step engine walks the researcher through 4 typed questions: the core job, the context, the current solution, and the outcomes to measure. The survey is then generated automatically — importance/satisfaction pairs for each outcome, pre-coded with jtbd-outcome-importance-* and jtbd-outcome-satisfaction-* codes so the analysis engine already knows how to read them.

Step 3: Define the persona pool. Instead of recruiting an anonymous panel, the researcher builds (or imports) a persona pool: B2B SaaS buyers, segmented by company size, role, and experience level. Each persona is resolved into a PersonaTraitVector deterministically — a senior engineer at a 200-person SaaS company will have high techSavviness, moderate priceSensitivity, and whatever satisfaction their stated pain points imply.

Step 4: Run a validation simulation before spending a dollar on real fieldwork. The simulation engine runs the survey against 500 synthetic agents drawn from the persona pool. It surfaces distribution skew, floor/ceiling effects, and coverage gaps — within seconds. The researcher sees whether the instrument is working before any real person takes it.

Step 5: Run live fieldwork (or skip it if the simulation is sufficient). Real respondents take the survey. The AI interviewer is available as a supplement — for respondents who want to elaborate, it holds an adaptive conversation and extracts structured answers with confidence scores and depth ratings (surface / moderate / deep).

Step 6: Analysis runs automatically on close. The JTBD analysis engine pairs importance and satisfaction questions by code, computes Ulwick opportunity scores for each outcome, and ranks them:

// Opportunity score = importance + max(importance - satisfaction, 0)
// High importance + low satisfaction = highest priority
const oppScore = opportunityScore(importanceStat.mean, satisfactionStat.mean);

No export. No Excel. No SPSS. The results are in the dashboard the moment the last response arrives, structured as an opportunity matrix with priority tiers already classified.

Step 7: The agent answers follow-up questions. The Survey Analytics agent can answer questions like "Which segment drives the largest opportunity gap?" or "How does the enterprise cohort compare to SMB?" in natural language, against the live data.

Total time: Hours to days. Cost: fraction of traditional. Output: live, queryable intelligence.

Why the Architecture Is the Difference

The speed and cost gap isn't just operational. It's structural.

Traditional MR platforms were built to collect data. OAIRA was built to produce intelligence. The difference shows up in every layer:

• The respondent is modeled, not anonymised
• The methodology is encoded, not assumed
• The questions know what they mean, not just what they ask
• The analysis is a computation, not a report
• The AI is woven into the research loop, not applied after the fact

You can't bolt person-centric intelligence onto a question-centric data model. The architecture has to be different from the start — and that's the bet OAIRA was built on.

Read the previous posts in this series: The Taxonomy Was Wrong and What Person-Centric Research Looks Like in Code.