Research Ops at Scale: Mining Transcripts & Field Inquiries

The Real Bottleneck Is Not Interviewing. It Is Traceable Synthesis.

Teams love to talk about "doing the research." What they usually mean is recruiting, interviewing, shadowing, and maybe running a survey. Hard work, yes. But the operational cliff appears one week later, when the corpus is large enough that nobody can hold it all in working memory. At that moment people start trimming the data to fit the wall rather than expanding the wall to fit the data. The corpus shrinks. Quotes get paraphrased. Saturation gets declared because the calendar is tired.

ASD treats that failure as a systems problem. Research operations is a pipeline, not a heroic workshop. The human designer still owns rapport, consent, framing, and participant-facing judgment. The platform owns the boring rigor around storage, method contracts, acceptance rules, review, and replay. Once I separate those responsibilities, 200 interviews stops sounding reckless and starts sounding like throughput.

That separation is why the CLI matters. The command surface is plain: asd project-create, asd evidence-add, asd method-run, asd artifact-write, asd review, asd factcheck. The engine is telling me that research is not a floating memo. It is a series of durable records with gates between them.

Calder Community Bank is the cleanest illustration. The board wanted whole-service discovery across SME onboarding, branch service, digital, and complaints. A traditional agency bid assumed sixteen weeks and quietly expected the corpus to collapse to forty interviews. The ASD posture was the opposite. Keep the corpus. Industrialize the processing. Protect the evidence boundary so the volume stays believable.

Research Plans Are Typed Artifacts, Not Prelude Text

The first move in a scaled study is to stop treating the research plan as throat-clearing. In ASD the plan itself is a registered artifact kind: research-plan. That changes the behavior of the whole engagement. If the plan is an artifact, it must declare sample, method, timing, and provenance in a form that can be reviewed, failed, rewritten, and handed off. A vague PDF becomes impossible.

The research-plan-design method makes that explicit. Its output kind is research-plan. Its acceptance rules are small but unforgiving: minimum 2 nodes, non-empty sample, non-empty method. Its Critic instruction is equally specific: reject any plan whose sample size or recruitment channel is left unspecified. That is the right level of rigor for planning. I do not need fake certainty. I do need named activities with declared coverage.

asd project-create --name "Calder Research Ops"   --client "Fictional composite — Calder Community Bank"   --sector banking   --service "SME onboarding, branch service, digital, complaints"

asd method-run --methodId research-plan-design   --projectId calder-research-ops-4e2f9a11

{
  "method": {
    "id": "research-plan-design",
    "name": "Research Plan Design",
    "phase": "research",
    "reviewGate": "critic"
  },
  "acceptance": [
    {
      "rule": "min-nodes",
      "min": 2
    },
    {
      "rule": "field-non-empty",
      "field": "sample"
    },
    {
      "rule": "field-non-empty",
      "field": "method"
    }
  ],
  "outputKind": "research-plan"
}

Once Calder's plan is an artifact, the bank's hardest questions become explicit research nodes instead of hidden assumptions. One node can cover abandoned SME onboarding cases. Another can cover branch-loyal seniors at closure-risk branches. Another can cover complaint handlers. The plan carries the research architecture in durable form, and that means the rest of the pipeline can attach itself to something real.

A plan artifact also improves handoffs. After the Critic passes it, the plan can be handed to the next role with open gaps visible. That matters more than people think. Research operations breaks when the fieldwork coordinator, analyst, and designer each believe they are working from the same plan while quietly editing different mental versions of it.

Contextual Inquiry Turns Fieldwork into Evidence Instead of Folklore

Large-scale transcript work gets most of the attention, but service design still begins in the messy world. I need to watch the banker re-enter a document because the branch scanner jammed. I need to see the rider miss the connection. I need to hear the parent explain the workaround while doing it. Contextual inquiry keeps research grounded in performed reality rather than post-rationalized explanation.

ASD's contextual-inquiry contract is compact and useful. It produces an insight-set. It requires at least 3 nodes, at least 1 evidence row per node, and a non-empty theme field. The Critic rejects any insight not traceable to a specific observed moment. That sentence is doing heavy lifting. It stops the designer, and the model, from upgrading mood into fact.

In Calder the field discipline looked like this: humans ran the branch, onboarding, and complaints shadowing; every note became either a document row or a quote row, depending on whether it was observed context or verbatim speech; the resulting evidence could then feed contextual-inquiry or transcript-mining without inventing a second evidence system. One research database. Multiple methods. Clean boundaries.

[
  {
    "id": "branch-queue-opacity",
    "label": "Branch visitors cannot tell whether the line is moving or stalled",
    "fields": {
      "theme": "status visibility"
    },
    "evidence": [
      {
        "evidenceId": "6e3150d6830b02c2f0cdb2b99bfa417b9f9e9dc9a17113e71d2d9913cd9d1be2"
      }
    ]
  },
  {
    "id": "sme-document-rework",
    "label": "Owners resubmit the same document because acknowledgement is missing",
    "fields": {
      "theme": "confirmation failure"
    },
    "evidence": [
      {
        "evidenceId": "a6a0d6ee6bf6f3ba13fd8fa5f739b04db769e2c26c5b51a0ec9a246fd0e33560"
      }
    ]
  },
  {
    "id": "complaint-looping",
    "label": "Customers retell the complaint because ownership disappears between teams",
    "fields": {
      "theme": "handoff opacity"
    },
    "evidence": [
      {
        "evidenceId": "f44379f1b00aa782c212d2a9c63b09189d7e688ef1d02c2428461d52f383fbb7"
      }
    ]
  }
]

That JSON is boring on purpose. Three nodes. Three themes. Three evidence ids. No mysticism. The platform is asking a simple question: can you point to the moment? If yes, write it. If not, keep working.

Transcript Mining, Coding Frames, and Honest Saturation

Transcript mining is where scaled research either becomes trustworthy or becomes a hallucination factory. The common failure mode is obvious: somebody pastes twenty transcripts into a chat window and asks for themes. The model obliges. The quotes are smooth. The themes feel plausible. The offsets do not exist. The extraction logic is unrecoverable. The corpus becomes a style exercise.

ASD's answer is not one magical tool. It is a contract plus a discipline. The transcript-mining method requires at least 5 evidence records before it will even run. Once available evidence exists, asd method-run --methodId transcript-mining returns the contract: phase research, owner researcher, output insight-set, acceptance min-nodes: 4, min-evidence-per-node: 2, and non-empty theme. The Critic rejects any insight that merely paraphrases a flagged line without adding a distinct theme. That last clause is essential. It stops the model from copying the corpus into a prettier voice and calling it synthesis.

asd method-run --methodId transcript-mining   --projectId calder-research-ops-4e2f9a11

{
  "method": {
    "id": "transcript-mining",
    "name": "Transcript Mining",
    "phase": "research",
    "reviewGate": "critic"
  },
  "inputs": [
    {
      "kind": "evidence-set",
      "min": 5,
      "note": "call, chat or interview transcripts"
    }
  ],
  "acceptance": [
    {
      "rule": "min-nodes",
      "min": 4
    },
    {
      "rule": "min-evidence-per-node",
      "min": 2
    },
    {
      "rule": "field-non-empty",
      "field": "theme"
    }
  ],
  "outputKind": "insight-set"
}

Calder used this contract against a rolling corpus. Interviews came in waves. So did evidence. The bank never waited for interview 200 before learning something. That would have been wasteful. Instead the transcript-mining pass re-ran on the growing evidence base, while the codebook evolved at declared checkpoints rather than by casual drift. Week 3 might still be immature. Week 7 might genuinely stabilize a theme. The point is that the platform preserves both the finding and the conditions under which the finding was produced.

Coding frames matter here. Calder did not let every analyst invent categories on the fly. The codebook version moved in declared steps: seed codes for access, effort, trust, status visibility, fees, handoffs, staff capability, and life events; then add or merge codes only at checkpoint reviews. That gave the team two benefits. First, disagreement became inspectable. If one agent tagged a line as status visibility and another tagged it as fees, the dispute had a bounded vocabulary and could be resolved against the codebook rather than by charisma. Second, rolling synthesis stayed comparable week to week. The cluster named in week 4 still meant the same thing in week 7 unless the codebook change log said otherwise.

The coding frame is also where good research operations resists false precision. A code is not a verdict. It is a lens. I can tag a line as handoff opacity without claiming I have already solved the bank's organizational design. The mistake is to let coding drift straight into solutioning. ASD prevents that by making the method output an insight-set, not a roadmap. The next role still has to do its own work.

Now saturation. I treat saturation as a reporting discipline, not a mystical threshold. If rural branch seniors have only 14 completed interviews against a planned 18, I say so. If decline cases in SME onboarding came in below target because the bank refused another contact wave, I say so. That honesty is not a weakness. It tells the next phase which claims are strong, which are moderate, and which need another pass.

Case Spine: Calder's 200 Interviews and Aster Grove's Synthetic Setup

Calder is the heavy-duty spine. Two hundred interviews. Forty-five shadow days. Eight hundred diary entries. A ten-week research program with a board ready to challenge every conclusion. The agent team handled the transcript-facing work: ingestion discipline, evidence extraction, rolling clustering, review gates, and factcheck. Humans handled interviewing, consent, and the judgment calls around quota trade-offs. The result was not "AI did the research." The result was that the human research team stopped drowning in post-fieldwork admin and could keep the full corpus alive long enough to learn from it.

Calder's weekly operating rhythm is worth naming because it is where scaled research usually breaks. Monday and Tuesday were field-heavy. Wednesday night the new transcripts were ingested and verified. Thursday the rolling synthesis pass refreshed cluster counts and highlighted contradictions. Friday the designer and client leads reviewed only the red items: quota gaps, PII incidents, weak clusters, and any Critic veto. That cadence kept the corpus alive without forcing a giant end-of-program synthesis panic. It also meant the board saw evidence maturity rising over time rather than being asked to believe a single dramatic reveal.

Seen this way, the agent team is less like a replacement researcher and more like a disciplined research-ops layer. It makes the infrastructure of inquiry explicit. That is what lets a 200-interview program remain legible enough to challenge, defend, and hand over.

Aster Grove is the complementary lesson. Article 39 begins with a fictional service and a live tutorial workflow. The service case is synthetic. The BUZZ roster and Canvas round trip are real. That makes it the perfect example of how to start safely when I need to teach the loop, rehearse a method, or demonstrate a host integration boundary. I create an isolated project, add synthetic evidence rows with clear labels, then run the method and review loop honestly as synthetic practice. Nothing in that move is lesser. It is only dangerous if I later pretend the seeded evidence came from live participants.

asd project-create --name "Aster Grove Makerspace"   --client "Fictional composite — Aster Grove City Libraries"   --sector "public libraries and community making"   --service "makerspace equipment lending and workshop programming"

asd evidence-add --projectId aster-grove-makerspace-6a8498ef   --source librarian-01 --kind quote   --body "Members ask what they can make before they ask what they can borrow."

asd evidence-add --projectId aster-grove-makerspace-6a8498ef   --source usage-2026-08 --kind telemetry   --body "Laser cutter bookings full 9 of 12 Saturdays; induction no-show rate 27 percent."

asd evidence-add --projectId aster-grove-makerspace-6a8498ef   --source policy-03 --kind document   --body "Members must complete induction before borrowing supervised equipment."

asd method-run --methodId transcript-mining   --projectId aster-grove-makerspace-6a8498ef

That shell block is the right way to teach or rehearse. It uses real commands. It uses the real evidence vocabulary. It keeps the fictional boundary visible in the project name, client field, and source rows. It does not invent a parallel demo mode.

Between Calder and Aster Grove, the operational lesson becomes clear. Scale is not the enemy. Ambiguity is. Calder proves that a 200-interview corpus can stay tractable when the plan, evidence, method contract, review, and factcheck all stay explicit. Aster Grove proves that synthetic evidence can be legitimate when it is labelled, isolated, and never upgraded into fake field proof. Same engine. Different evidence boundary. Same honesty rule.

So here is the operational formula I keep coming back to. Start with a typed research plan. Run contextual inquiry where lived behavior matters. Mine transcripts against a declared contract instead of a vibe. Track coverage honestly. Keep synthetic setups clearly synthetic. And never let scale tempt you into summarizing away the evidence. Once I do that, the research operation stops being a bottleneck and starts being a durable production capability.

What matters is repeatability. When another designer opens the project six months later, the plan, evidence, codebook, gaps, and review rows still explain themselves.

Teams copying this operation usually want a concrete starter sequence. Week one: create the project, write the research plan artifact, and load the codebook you intend to hold yourself to. Week two: capture evidence in bursts, running evidence-query at the end of each burst so gaps surface while fieldwork can still fill them. Week three: run method-run for synthesis, write the insight register, and let the Critic reject every claim that leaned on paraphrase instead of verbatim rows. That cadence fits a normal sprint, produces an auditable register, and, most importantly, survives the departure of whichever person happened to remember the interviews.