§1 · Chambers

1.1 The shape of a Carrier experiment

Every Carrier experiment has the same nested shape. A participant who opens the experiment URL is assigned to a chamberline — the condition they will experience. Their chamberline is an ordered sequence of chambers, each of which is a small group of participants (human, AI, or both) who are matched once and remain together for the duration of that chamber. Inside each chamber, participants progress through an ordered list of segments — the activities that constitute the chamber, of which a real-time conversation is the most common.

This three-level structure is the backbone of Carrier:

The three levels exist to separate three concerns that are easily entangled when designing an interactive study:

• Chamberlines isolate the condition. Different chamberlines represent different experimental arms; a participant sees exactly one.
• Chambers isolate the matched group. Within a chamber, who you are with does not change.
• Segments isolate the activity. Within a segment, what you are doing does not change.

The remainder of this chapter introduces each level in turn.

§1 · Chambers

1.2 Chamberlines: the unit of condition

1.2.1 Why chamberlines

In a typical lab study you might compare two or three experimental conditions — say, high-anonymity versus low-anonymity discussions of a controversial topic. A chamberline is Carrier's representation of exactly that: a complete journey that one group of participants will take through the experiment. Multiple chamberlines in the same experiment correspond to multiple between-subjects conditions.

A participant is assigned to a single chamberline at the start of their session and does not leave it. Within-subjects comparisons (the same person experiencing two manipulations) are typically built inside a chamberline, by sequencing chambers that differ along the manipulated dimension; between-subjects comparisons (different people in different manipulations) are built across chamberlines.

1.2.2 Assigning participants to chamberlines

Carrier offers four assignment methods, configured at the experiment level:

Survey-based assignment is the most flexible. The global pre-survey runs before chamberline assignment, so any response collected there is available as a routing variable; this is the same mechanism described in §4.

1.2.3 What lives on a chamberline

A chamberline is, formally, a name plus an ordered list of chambers plus optional assignment criteria. There is no further configuration at this level — chamberlines are intentionally thin, so that a researcher can read the shape of an experiment by scanning the chamberline names and their chamber sequences in the builder.

§1 · Chambers

1.3 Chambers: the unit of matched group

1.3.1 Why chambers

A chamber is the basic unit of togetherness in Carrier. Once a participant enters a chamber, they are matched with the other occupants of that chamber and they stay together until the chamber ends. Within a chamber, the cast does not change.

This is a deliberate constraint. Many interactive studies depend on participants having a stable conversational partner across multiple tasks — a discussion followed by a joint ranking, for example, or a chat followed by a rating of the other person. In Carrier, those sequential activities belong in the same chamber and share its participants. Crossing a chamber boundary, by contrast, dissolves the group: the next chamber re-matches its occupants from the pool of participants who have reached that point.

1.3.2 Matching at the chamber boundary

Matching happens once, at the start of each chamber. Participants who finish the previous chamber (or, for the first chamber in a chamberline, who have completed the global pre-survey) enter a waiting pool. As soon as enough participants are present to fill the chamber's required slots, the chamber begins.

A slot is a description of the kind of participant the chamber needs. Each slot has a type (human, LLM chatbot, scripted chatbot, or agent) and a role (communicator, mediator, or processor; see §3). For human slots, matching can additionally require certain variable values — for example, that the chamber contain one self-identified novice and one self-identified expert. Variable-based matching is the topic of §4.

When a matching attempt does not assemble enough participants within a configured interval, Carrier applies a chamber-level fallback policy. The fallback is part of the chamber's configuration; common choices are to keep the participant waiting, to fill the missing slot with a default agent, or to end the run gracefully with a completion code. The choice is the researcher's, not the participant's.

1.3.3 What lives on a chamber

A chamber carries several pieces of configuration:

• A name and identifier, used in the dashboard and in exported data.
• A communication channel: text, audio, or video. The channel determines what the chat segment looks like and what data is recorded (transcripts, audio files, recorded video, or any combination).
• A slot definition, listing the roles to be filled and the type each slot expects.
• An ordered list of segments, described in §2.
• An optional pre-survey shown to each participant before they enter the chamber, and an optional post-survey shown after they leave.
• A maximum participant count — the total number of slots.

Chamber pre- and post-surveys are distinct from the experiment's global pre- and post-surveys. The global surveys run once per participant, at the very beginning and end of the run; the chamber surveys run once per chamber. Researchers typically use the global surveys for demographics and consent, and the chamber surveys for state measures that need to be taken before and after each manipulation.

Segments — the activities a matched group moves through inside a chamber, and the parameters of each — are the subject of §2. Roles are the subject of §3.

§2 · Segments

2.1 The segment system

A chamber's segments are its inner timeline: the participants are already matched, and now they move together through an ordered series of activities. Each segment is a single, self-contained activity — showing a slide, holding a conversation, voting on options, ranking items, watching a video, or completing a short embedded survey — with its own timing and transition rules.

Segments are deliberately fine-grained. A “thirty-minute deliberation” study in Carrier is usually not a single thirty-minute chat segment but a sequence: a slide introducing the topic, a timer giving participants a moment to think, a chat segment for the deliberation itself, a ranking segment to record the group's collective answer, and a short survey at the end. Each piece is configured separately, recorded separately, and can be skipped, repeated, or replaced without touching the others.

§2 · Segments

2.2 The catalogue of segment types

Carrier ships fourteen segment types. The Compatible with AI column marks the types a non-human participant can contribute to — LLM chatbots, scripted chatbots, or agents. The conversational and choice-based types can; the read, listen, wait and integrity types cannot, because there is nothing for a non-human participant to do. The Embeddable column marks the types that can run as an overlay on a chat rather than taking the screen to themselves, which is the subject of §2.3.

Each type has its own reference entry below, from §2.6 onwards: what the participant sees, what it is for, and every parameter its configuration panel exposes.

§2 · Segments

2.3 Standalone and embedded segments

Most segment types occupy the participant's entire screen for the duration of the segment. We call these standalone segments: they take their turn in the chamber's timeline, run to completion (or timeout), and then yield to the next segment.

Most non-chat segment types can additionally be configured to run embedded inside a chat segment. An embedded segment is rendered as an overlay on top of an ongoing chat, so that participants can act on it — vote, rank, write, watch a clip, read an instruction — without leaving the conversation. The chat continues to record messages in the background, and the embedded child appears only when its start trigger fires.

Embedded display is supported for the selection, ranking, pdf, social, input, task, slide, instruction, timer, media, and survey segment types. Two segment types are excluded outright: chat (it is the parent container; you cannot embed a chat inside a chat) and attention-check (no embedded renderer — attention checks always run standalone). A third, process, is offered the setting by the builder but has no embedded renderer either, so an embedded process segment shows the participant an error rather than a step — leave it standalone. On screens narrower than 900 px the runtime additionally falls back to standalone rendering for every segment, so the layout never breaks on mobile.

Embedded segments are useful when the activity is part of the conversation rather than an interruption to it. Two examples:

• Periodic polling during a deliberation. Ask participants to vote at three points (after one minute, after three minutes, after five minutes) while they continue talking. Each vote is a separate embedded selection segment with a different embedded-start trigger.
• Pacing a ranking activity to chat progress. Show a ranking overlay only once the conversation has produced enough material to rank — for example after a fixed number of chat messages, or after a fixed time offset from the start of the chat.

An embedded segment adds three configuration parameters beyond its standalone equivalent:

A chat segment with one or more embedded children may use an additional transition mode, embedded-complete, which ends the chat when every embedded child has completed. This is the canonical way to build a chat segment whose end is gated on the group having voted (or ranked, or read the instruction), rather than on a fixed duration. An optional fallback timeout on the chat itself is a safety net for chains whose start triggers might never fire — for instance an after N messages trigger if the participants never reach that message count.

For an attention-check segment (or any activity that needs the participant's complete attention), keep the display mode at standalone — the chamber timeline yields to it the same way it would for a survey or instruction.

§2 · Segments

2.4 Inline and split view

An embedded segment can occupy the chat in one of two ways, chosen with the Embedded Layout setting.

Inline renders the child as a card appended into the message stream itself. The card scrolls with the conversation, in the position the conversation had reached when it appeared. This suits short interruptions — a vote, a one-line question — where the activity is a moment in the discussion rather than a task beside it.

Split docks the chat into a column and gives the child its own pane alongside. Nothing scrolls away: participants read, watch or work in one pane while talking in the other. This is the layout for material that has to stay on screen — a document being discussed, a task being performed collaboratively. The pdf segment is the only type that defaults to it, because reading a document while discussing it is the case it exists for.

Card width and card height size the child as a percentage of the available area, defaulting to 75 % and 35 %.

§2 · Segments

2.5 Timing, transitions, and participant pacing

Every segment has its own timing and transition rules, which together determine how long participants spend on it and how they advance. These are the four parameters that matter most:

• Duration — the maximum time the segment may run. If left unset, the segment has no automatic deadline.
• Minimum duration — the earliest moment at which a participant may advance. This is the standard way to enforce a floor on engagement (a “read for at least 30 seconds before continuing” instruction slide, for example).
• Warning time — how long before an auto-advance the participant is warned. Useful to prevent surprise transitions in long segments.
• Transition mode — the rule for moving on:

The pacing choice has substantive consequences. A sync transition gives participants the experience of a shared rhythm, but it also means that the slowest participant determines the group's pace, which can be frustrating in long studies. A manual transition lets each participant move at their own speed, but it can break the group character of a chamber if used for the chat segment itself. A host transition is most useful during pilot testing — the experimenter can step the group through the timeline by hand to debug pacing.

§2 · Segments

2.6 The slide segment (deck)

A slide segment is a deck: an ordered set of slides that the participant steps through one at a time. That is the whole distinction from instruction, and it is worth stating before anything else — an instruction is one thing to read and acknowledge; a slide segment is a sequence to present. A study brief with a Continue button underneath belongs in instruction (§2.7), which has the better authoring surface for prose. A stimulus that unfolds across four screens — a scenario, then a chart, then the manipulation, then the question framing — belongs here, as one segment rather than four.

The participant sees one slide filling the activity area, with the usual chamber chrome around it — segment progress indicator, countdown clock and participant list in the sidebar, subject to the chamber's own settings. Beneath the slide sits a Next button on every slide but the last, and a Back button beside it on every slide but the first, and then only if the segment allows going back, which it does not by default. On the last slide the deck's Next disappears and the segment's own Continue takes its place, so leaving the deck and leaving the segment are never two separate clicks. That chamber progress indicator counts segments: there is deliberately no counter for the deck itself, so the participant is not told how many slides remain, because knowing changes how carefully the early ones are read. If a slide sets a minimum dwell, the button it holds renders disabled with “Available in 12s” counting down beside it. There is nothing to submit inside a slide: the participant reads or watches, then moves on.

Slides are built in the Deck Builder, a modal opened from the segment's configuration panel. The left column is the slide list — add, duplicate, reorder, delete — and the right pane holds the selected slide's layout settings and its blocks. A block is one piece of content of a declared type: a heading, a text block written as Markdown in the same full-screen editor the instruction segment uses, an image or video chosen from the experiment image library or given by URL, or an html block injected into the page exactly as authored. Blocks stack in the order listed, and nothing is written back to the experiment until Save deck.

What you put in an HTML block

<h2>Round 1 — the proposal</h2>
<p>Your group has <strong>£10,000</strong> to allocate between three bids.</p>
<blockquote>{{var.first_name}}, you have been asked to speak first.</blockquote>

What the participant sees

Heading, text and HTML blocks support {{var.X}} tokens, resolved per participant when the segment begins (see §4.5) and applied block by block, which is how one deck serves as a personalised briefing across an entire sample. Every slide's tokens are resolved at that same moment, not when the slide is reached, so a token on slide five carries the value it had when the participant entered the segment.

Two settings live on the segment itself; everything else that shapes the deck is per slide, edited in the Deck Builder.

There is no Data Sharing control on a slide, and no results display. Those appear only on segments that collect a response from the participant, which a deck does not — though it does record how the participant moved through it.

Every slide change writes a view log to the segment's submission: one entry per visit, carrying the slide's id and position, the millisecond offsets at which it was entered and left, and the resulting dwell. A slide visited twice appears twice, so revisits under Allow participants to go back are countable rather than merged. Alongside it sit slidesViewed, deckSize and deckCompleted, the last recording whether the participant actually reached and left the final slide. All of it arrives in the Segment Submissions section of the data export (§6.5), with the log itself as a JSON string in the submission's data.

A slide segment authored before decks existed keeps working untouched: it is read at run time as a one-slide deck, its old content becoming a single block and its old layout mapping onto the new width and alignment. There is no migration and nothing to re-save — the old fields stay on disk exactly as they are, and the segment's configuration panel says so. They stop being read the moment the segment is saved from the Deck Builder, which is what gives such a segment a slides array.

2.6.1 Standalone and embedded display

A slide runs standalone by default, and can be embedded inside a chat segment — it is one of the types the builder offers the Display Mode dropdown for. Embedded, it defaults to the inline layout, appearing as a card in the message stream with its own Continue button and, optionally, pinned to the top of the chat while it is active; the alternative split layout mounts the content in a pane beside a docked live chat. Two conditions gate this. The embedded segment must sit immediately after the chat segment it belongs to in the chamber timeline, which is how the builder decides whose child it is. And on viewports narrower than 900 px the runtime ignores the embedded setting and renders the slide standalone, so a participant on a phone sees a full-screen slide where a desktop participant sees a card in the conversation — worth knowing before treating an embedded slide as a controlled stimulus.

A deck works inside the card as it does full-screen: the slides replace one another in place, and the card's Continue stays hidden until the last slide is reached, so one click cannot skip the rest of the deck. The card's timing is the exception noted above — the Timing & Transition controls are replaced by the embedded triggers — but per-slide minimum dwell is set in the Deck Builder and keeps working either way.

§2 · Segments

2.7 The instruction segment

An instruction segment gives the participant one block of formatted prose and one button. The text is authored as Markdown and rendered on screen — headings, lists, emphasis, links, inline code, tables and rules all survive — in a column 800 px wide by default, centred horizontally, and centred vertically when the text is short enough to fit without scrolling. Beneath it sits a single primary button, labelled “Continue” unless renamed. That button is drawn disabled and stays disabled until the segment’s pacing conditions are satisfied; when a button delay is set, the remaining seconds count down inside the label itself — “Continue (5s)”, “Continue (4s)” — so the wait reads as deliberate rather than as a broken page.

This is the segment to reach for whenever the participant must read something and acknowledge it: the study brief, a consent-style preamble, the task instructions before an interactive segment, or the framing text that differs between conditions. What separates it from slide is not the content but the shape: an instruction is one screen, and the segment is over when it is acknowledged, whereas a slide segment is a deck the participant walks through (§2.6). One prose screen with a button is an instruction; a sequence is a slide segment. The instruction also owns the acknowledgement itself — a renameable button, a delay before it becomes clickable — so the click can be made to cost the participant a measured number of seconds rather than being a reflex. Because the body is interpolated per participant before it is shown, one instruction segment can carry condition-specific text through {{var.X}} tokens instead of being duplicated once per chamberline (see §4.5). Interpolation is resolved when the participant enters the segment and is not refreshed afterwards, so a variable that changes mid-segment does not alter text already on screen.

What the participant sees

The instruction segment runs standalone by default, filling the screen, and can also be set to embedded so that it appears over a live chat. Embedded, it defaults to the inline layout — a card in the message stream — and can instead use split, where the prose fills the main area and the chat docks to a side panel; the latter suits a briefing that participants are meant to consult while they talk. It is one of the segment types whose interactive behaviour is rewired for the embedded path rather than simply drawn there, so the button delay and the disabled-button logic keep working inside the card. The usual embedding rules apply: the segment must sit immediately after a chat segment in the timeline to become its child, and on viewports narrower than 900 px the runtime falls back to standalone rendering.

§2 · Segments

2.8 The media segment

A media segment gives the participant one thing: a full-width player filling the content area — a video, an audio bar, or an embedded YouTube or Vimeo frame — with the shared Continue button beneath it. As with every segment, that button disappears when the transition mode is auto and early advance is off, in which case the clip is the whole screen and the segment ends on its own terms.

It exists so that a stimulus clip can be a step in the timeline in its own right, rather than something bolted onto a slide: a news vignette shown before a deliberation, an audio prompt each participant hears alone, a recorded briefing that must precede a task, or a debrief video at the end of a chamber. Because it is a distinct segment, it gets its own timing, its own transition rule, and its own row in the timeline — so “how long were they exposed to the stimulus” is a property of the design rather than something inferred from slide dwell time. The segment records no response of its own; it is exposure, not measurement, and the measurement belongs in whatever segment follows it.

What the participant sees

The segment can run standalone or embedded. Standalone is the default; embedded defaults to the inline card, and the split layout — clip in the content pane, live chat docked alongside — is the natural shape for “watch this while you discuss it”. The embedded form obeys the same gating as every other embeddable type: the segment must directly follow the chat segment it overlays, it takes the shared embedded start, stop and completion parameters, and on viewports narrower than 900 px it falls back to standalone rendering. Because media collects no response, the Data Sharing, results-display and anonymity controls that appear on the interactive types are absent here.

§2 · Segments

2.9 The PDF segment

A pdf segment puts a document on the participant's screen inside a plain frame drawn by the browser's own PDF viewer — so scrolling, zooming, page navigation, search and print are the browser's controls rather than Carrier's, and behave exactly as the participant already expects them to. Run standalone, the frame fills the segment area beneath the usual Carrier chrome (progress bar, countdown, participant list) with a Continue button under it. Run in its default split layout, the document takes the main pane and the live chat is relocated into a docked column beside it, so participants can argue about a text that stays in front of them. Run inline, it arrives as a card in the message stream with a document header and a minimise chevron.

Its purpose is to carry the stimulus — a vignette, a news article, a policy brief, a scientific paper, an information sheet — when the material is longer or more typographically demanding than a slide can carry honestly. It is a reading surface, not a response surface: a pdf segment records no response of its own. That is why the Data Sharing controls other segment types offer are absent from its panel — there is nothing to share — and why the only trace it leaves in the export is how long the participant had it open. Evidence that the document was actually read has to come from its neighbours: a minimum-duration floor on the segment itself, or a comprehension question in the segment that follows it.

What the participant sees

The pdf type is embeddable, and is the only segment type whose factory defaults are embedded rather than standalone, and split rather than inline — the split-screen reader is treated as the normal way to use it, and the standalone document as the special case. Two gates apply. The split layout needs a real chat parent: the runtime looks for a live chat segment to dock, and if the PDF is not running under one it logs a warning and quietly falls back to the inline card. And embedding of any kind is abandoned below a 900 px viewport, where every embedded segment reverts to standalone rendering, so a participant on a phone reads the document full-width and never sees the chat beside it.

§2 · Segments

2.10 The timer segment

A standalone timer segment clears the activity area and leaves one centred card on screen: a line of text — “Please wait...” unless the researcher changes it — a large minutes-and-seconds readout that ticks down once a second, and a horizontal bar that fills as the wait elapses. The usual segment shell remains around it: the progress indicator, the participant list and the chamber clock, subject to the chamber's own visibility settings. What is not there is a Continue button. The timer renderer emits no navigation controls at all, so there is nothing for a participant to press; they wait, and the segment ends itself. If they reload the page or drop and reconnect, the remaining time is recomputed from the server's record of when the segment started, so a refresh does not restart the wait.

A timer is a pacing instrument rather than a measurement one. It records nothing, accepts no input, and gives non-human participants nothing to do. Its uses are all variants of buying time on purpose: a short settle-in pause after matching, before a discussion begins; an enforced deliberation delay between reading a case and deciding on it; a synchronising beat while slower members of the chamber finish an earlier activity; an inter-trial interval between repeated measures. Two nearby instruments are often the better choice. If the requirement is “spend at least thirty seconds on this page”, a Min Duration on the page's own segment enforces that floor without also imposing a ceiling (§2.5). If the wait exists because the server is computing something, a process segment ends when the work finishes rather than when a clock runs out.

The type configuration panel offers six controls. Two of them reach the participant; the other four are documented here because they are visible in the builder, not because they do anything.

What the participant sees

2.10.1 Standalone and embedded

The timer is one of the embeddable types: its Display & Sharing card offers Standalone and Embedded (overlay on chat), and the default embedded layout is inline — a card in the message stream — with split available. It carries no gating beyond the general rules for embedded children: the segment must sit immediately after the chat it belongs to, and below 900 px of viewport width the runtime renders it standalone instead. The card is cosmetic, though. The embedded path draws the message and a number, but never starts the per-second countdown, so the figure on the card is a static one that does not move; and because choosing Embedded hides the whole Timing panel, the duration it is drawn from can no longer be edited in the inspector. An embedded pause should therefore take its timing from the embedded stop trigger (“auto-dismiss after N seconds”) and be read as a notice rather than a clock.

§2 · Segments

2.11 The survey segment

A survey segment hands the main area over to a Survey.js form. The questionnaire arrives with its own chrome — pagination, Next and Previous buttons, required-field markers, inline validation messages and a Complete button — rendered inside the usual segment frame, with the progress indicator, countdown clock and participant list showing or hidden according to the chamber’s settings. Standalone, Carrier adds no advance button of its own: the Survey.js Complete button is the only way forward, and pressing it saves the answers and moves the timeline on in one motion.

It is the same survey engine that renders the experiment-level and chamber-level surveys, so the segment is not the place for a long battery that could simply be attached to the chamber. What the segment adds is position and consequence. Position, because it occupies an exact slot in the chamber’s inner timeline — a manipulation check wedged between two chat segments, a mood measure taken immediately before a deliberation rather than fifteen minutes earlier, a confidence rating collected the moment a task ends. Consequence, because it is the only survey surface that can end or divert the run on the strength of an answer, which makes it the natural home for screeners and exclusion criteria as well as for measures. Each answer is stored under a researcher-chosen key, so a survey segment is also the usual way of manufacturing a variable mid-run for later matching (§4.3) or prompt interpolation (§4.5).

What the participant sees

The survey is embeddable, but defaults to standalone. Embedded, it mounts the same Survey.js model into a card inside the chat stream — inline by default, at 75% of the chat width and 35% of its height, which is cramped for anything longer than a question or two. The split layout gives the form the main area with the live chat docked beside it, but it needs a chat segment to dock into: mounted anywhere else it silently falls back to the inline card. Embedding as a whole is gated on viewport width — below 900 px the segment renders standalone regardless of the configured mode, so a mid-conversation manipulation check becomes a full-screen one on a phone. General embedding behaviour, start and stop triggers and completion behaviour are covered in §2.

§2 · Segments

2.12 The input segment

A participant meets an input segment as one question and one field to answer it in: a four-row textarea, a single-line text box, or a number field, carrying whatever placeholder text the researcher supplied. A hint line may sit underneath — “Value range: min: 0, max: 100” for a numeric field — and below that sits the ordinary Continue button. That button is live-gated: it enables and disables on every keystroke as the answer starts and stops satisfying the segment’s validation rules. It does so silently. There is no error message, no highlight on the field, and no explanation of what is wrong — only a button that will not respond.

The segment exists for the case where there is exactly one thing to ask: an open-ended justification for a choice just made, a one-line explanation, a numeric estimate, a willingness-to-pay figure. It is the lightweight alternative to a survey segment — one prompt, one answer, no form schema to author — and its answer is a first-class segment submission, readable by later segments and by trigger conditions as a variable (§4.2) and carried into the export as the segment’s recorded data (§6.5). Note that non-human participants can submit into an input segment as well as humans (§5.5), which the catalogue table in §2 and Appendix C both fail to record.

2.12.1 Parameters

What the participant sees

2.12.2 Standalone and embedded

input runs either standalone, replacing the chat view for the duration of the segment, or embedded as a card laid over a live chat. The embedded renderer implements it properly — the validation, the button gating and the debounced autosave all keep working inside the card — and an embedded input is treated as a child of the nearest preceding chat segment. The default is standalone; when Embedded is chosen, the Timing and Transition cards disappear in favour of a start trigger and a stop trigger, and the default layout is inline (a card in the message stream) rather than split (a content pane beside a docked chat column). Two cautions are specific to this type: the inline card’s default height of 35 per cent of the chat viewport is tight once a prompt, a four-row textarea and a hint line are stacked inside it, and a time-based stop trigger will dismiss the card mid-sentence, discarding whatever had not yet autosaved. Below 900 px of viewport width, and for mediator and observer views, an embedded input falls back to standalone rendering.

§2 · Segments

2.13 The selection segment

A selection segment puts a single question on the screen and asks every participant in the chamber to answer it. The question is rendered from markdown at the top of the segment area; beneath it sits either a list of options — radio buttons in single mode, tick boxes in multiple mode, with a “Select 1-3 options” hint under the list when more than one answer is allowed — or, in slider mode, a track with an anchor label at each end and a large live readout of the current value. The Continue button below starts disabled and only becomes clickable once the number of ticked options falls inside the Min/Max range (and any minimum duration has elapsed); clicking it before then flashes the option list red rather than advancing. A slider is the exception: it always reports a value, so its Continue is live from the first paint.

It is the segment to reach for whenever a design needs a discrete answer on the record: a vote at the end of a deliberation, a forced choice between two framings, a manipulation check, or — in slider mode — a Likert or visual-analogue rating. Its answers are not merely logged. Every submission is readable downstream as segment-submission:<segId>:selections, segment-submission:<segId>:optionValues.0 or segment-submission:<segId>:sliderValue, so a choice made here can steer a later chamber, feed an aggregate, or interpolate into an instruction (§4). It is also one of only two types — with ranking — for which a scripted or LLM participant can be configured to submit a confederate answer alongside the humans (§5).

2.13.1 Parameters

What the participant sees

Timing and transition are shared with every other segment, but a new selection is created user-paced rather than timed: no duration, no warning time, and transition mode manual, so it waits for the participant instead of running a clock. Setting a duration turns it into a timed poll; setting mode sync holds the whole chamber until everyone has answered.

2.13.2 Standalone and embedded

Selection renders in both display modes, and embedding it is the canonical use of the embedded mechanism: a poll that overlays a live conversation lets a group vote without leaving the discussion, and a chat whose transition mode is embedded-complete ends exactly when the vote is in. The default is Standalone, and the default embedded layout is Inline. The gating is positional rather than a setting: an embedded segment becomes the child of the nearest preceding chat segment in the same chamber, so a segment that is not preceded by a chat has nothing to overlay. Two run-time conditions force a fallback to standalone rendering regardless of the configuration — a viewport narrower than 900 px, and any mediator or dashboard observer, who sees the mediator view rather than the interactive widget.

§2 · Segments

2.14 The ranking segment

A ranking segment shows a prompt line and, beneath it, a vertical list of the items to be ordered. Each row carries a grip handle on the left, its current position number, and the item's label. Rows are reordered by dragging them past one another; the position numbers renumber the moment a row is dropped, and every drop records the new order. Below the list sits the standard Continue button. There is no keyboard or button-based alternative to dragging at runtime — the up/down arrows that appear in the builder's playtest preview are a preview affordance only — so a ranking segment assumes a pointer.

Researchers reach for it in three situations: eliciting a preference order over a fixed set of alternatives, asking a group to set priorities, and recording a collective ordering at the end of a deliberation. The third is the common case, and it is usually configured as an embedded card over a chat so the group can rank while still talking. Like selection, a ranking's output is readable downstream as a segment-submission variable (§4.2), and a scripted or LLM participant can be configured to submit an ordering alongside the humans (§5.5).

2.14.1 Parameters

What the participant sees

2.14.2 Display modes

Ranking is one of the embeddable types. It defaults to standalone with an inline embedded layout, and the builder places no restriction on where an embedded ranking may sit — at runtime it is treated as a child of the nearest preceding chat segment in the chamber, so an embedded ranking with no chat before it has no parent to overlay. Two conditions force it back to standalone regardless of configuration: a viewport narrower than 900 px, and a viewer watching as a mediator or observer. Shared results appear beneath the list in either mode.

§2 · Segments

2.15 The chat segment

A chat segment fills the participant's screen with one scrolling message stream and, beneath it, a text box that grows as it is filled and a paper-plane send button. Around that sits the usual segment shell — segment progress, the countdown clock and the participant list in the left sidebar, unless the chamber or this segment turns them off. Every other occupant of the chamber writes into the same stream, and nothing in the interface distinguishes them by kind: another human, an LLM chatbot, a scripted chatbot and an agent all produce ordinary message bubbles, complete with typing indicators that appear and clear on their own. There is one room, everyone is in it, and there is no channel to switch to. Participants holding a non-communicator role see a different screen entirely — a processor gets a read-only observation column beside its draft panel, a mediator gets the broadcast console — described in §3.1.

This is the segment used for deliberation, negotiation, dyadic advice-giving, interviewing, and any design where the dependent measure is what people say to one another. It is also the surface most of the trigger system watches: keyword, message-count, sequence and after-bot-message triggers (§5.1) are all evaluated against a chat segment's message stream, so a chamber's scripted behaviour usually lives or dies here. Finally, it is the host container for embedded child segments — the way a vote or a ranking can be put to a group mid-conversation without taking the conversation off screen.

2.15.1 Type configuration

What the participant sees

2.15.2 Control events

Control events are the one part of the chat panel with no equivalent elsewhere in the builder, and the reason a chat can be made to close itself on the state of the conversation rather than on the clock. Each event pairs an action with a condition; the modal opened by the + button shows only the sections the chosen action needs.

2.15.3 Display

The chat segment is the only type with no Display & Sharing card at all — it has neither a display-mode dropdown nor a data-sharing dropdown, because it is never the thing being displayed on top of something else. A chat is always standalone, and the participant client refuses to render it in embedded mode even if a configuration asks for one. The relationship runs the other way: a chat is the background that embedded children are drawn over, either as an inline card appended to the message stream or, with the child's embedded layout set to split, in a pane beside a docked chat column (§2). Below a viewport width of 900 pixels every embedded child falls back to standalone, which means that on a narrow screen the child replaces the chat instead of overlaying it — worth knowing before recruiting participants on mobile devices. One further chat-only detail has no control in the builder: a prompt value set on the segment through an imported configuration renders as a standing banner above the message stream.

§2 · Segments

2.16 The social feed segment

The social segment renders a mock social-media platform — a feed of researcher-authored posts with photos, captions, like counts, and seeded “crowd” comments. The platform takes over the entire screen for the duration of the segment: participants see only the mock platform's own chrome (its top bar and feed), not the Carrier segment UI, for a fully immersive simulation. Participants browse the feed and can comment, reply, like or vote on posts and comments, follow authors, and click decorative share/save buttons.

Three layouts are available per segment:

• Instagram-like — media-dominant cards, double-tap to like, caption below the image, collapsed comments. Replies nest one level.
• Facebook-like — caption-first cards, a labeled Like · Comment · Share bar, bubble comments. Replies nest one level.
• Reddit-like — a forum layout: an up/down vote gutter with a running score on every post and comment, title-led posts (a post can be an image post, a text post, or a link post), optional community and flair labels, and comment threads that nest to any depth. Indentation re-bases every five levels behind a “Continue this thread →” link, so a deep argument stays readable.

What the participant sees

Progression is time-based: new social segments default to a 3-minute auto-advance timer (adjust the duration in the segment's Timing panel), and the remaining time appears as a small pill in the platform's top bar that turns amber as the end approaches. If you configure a manual transition instead, a subtle “Continue →” button appears in the platform chrome.

The feed connects to the agent system through account binding: each account in the feed is either crowd (decorative — it authors posts and seeded comments only) or agent — bound to one of the chamber's non-human participants by display name. When the participant comments, the comment travels through the same pipeline as chat messages, so every trigger type and LLM configuration works unchanged; the bound agent's reply appears in the feed as its account, threaded under the comment that triggered it. At segment start the platform writes one hidden context message per post into the conversation history, so LLM agents know what the posts say without any extra configuration.

Each agent account also has a scope: by default it responds across the whole feed, or you can scope it to specific posts by ticking them on the Feed Builder’s own timeline. Scoped agents only react to comments on their posts — a comment elsewhere never reaches them — and unbound agents stay silent in social segments. LLM agents additionally receive a scope-aware identity block in their system prompt (“you are commenting as sona.fields; you only take part in these posts: …” with the posts' captions and seeded comments), so their replies stay in character and grounded in the right content. This lets you run several agents as distinct personas, each owning different posts.

The fastest way to set a persona up is the New agent button beside an account's bind dropdown: give it a name, a persona prompt, and a provider/model, and Carrier creates the agent (with an LLM reply-to-comments trigger), adds it to the chamber, and binds it — one step, no script builder needed. Afterwards, the Agents tab is where that persona is tuned: prompt, model, temperature, context window and timing, without leaving the Feed Builder to hunt for the agent on the canvas. A readiness checklist (agent accounts bound · responding triggers present · API key stored · every post arriving before the segment ends) appears both in the segment inspector and behind the chip in the Feed Builder’s header, and each agent's own config panel still shows where it is bound (“replies as sona.fields on posts p2”) or warns when it isn't.

Feed content is edited in the Feed Builder (posts, seed comments, accounts, bindings, scopes, layout, settings). Its header’s Data menu bundles the file actions — import as JSON (the full configuration) or CSV (a flat, spreadsheet-friendly content format — accounts are derived automatically from the author handles and existing agent bindings survive re-import), export in either format — with a Template JSON download of a worked example to start a bulk edit from, plus a downloadable starter kit (worked CSV, plain-language guide, and sample images) for spreadsheet-based authoring. Seven managed variables are created automatically per social segment — social_<segmentId>_comments, _agentReplies, _likes, _follows, _actionLog, _commentCount, and _votes — and can be used anywhere other variables can. _votes is only ever filled by the reddit layout; on the other two it stays empty because there is nothing to vote with.

If you built a social segment before the reddit layout shipped, it still has only the original six variables. Carrier does not add _votes to a saved experiment on its own — open that segment's Feed Builder and save (or re-import its CSV) and the variable appears. Votes are recorded in _actionLog either way; it is only the dedicated _votes variable that has to be created this once.

§2 · Segments

2.17 The task segment

In its plain form a task segment shows a block of instructions, then a labelled text box with a live character counter reading “0 / 500 characters” and a Submit button that stays greyed out until the response is long enough. Submitting locks the box, removes the button and leaves a “Response submitted” confirmation in its place. Give the segment an iFrame URL and an external page — an existing web experiment, a game, a reaction-time tool — is loaded in a sandboxed frame between the instructions and the text box. Turn on the custom application and the segment is handed over entirely: the instructions shrink to a short Markdown header, the researcher's own HTML fills the rest of the screen, and Carrier's text box, counter and results panel are not rendered at all.

The task segment is the escape hatch for activities Carrier has no purpose-built segment for, and it is used at three escalating levels: a prompted free-text response with length limits; an externally hosted tool that posts a result back when the participant finishes; or a full custom application whose internal state is bound to experiment variables in both directions. That last case is what distinguishes the segment from a dressed-up input. A belief slider, a network diagram, an economic game or a drawing canvas can write its state into variables that surveys, matching rules, visibility gates and bot prompts all read (§4.2), and can be handed live variables back as they change — so a bespoke instrument becomes part of the experiment rather than an external detour whose data has to be reconciled afterwards. The trade-off is that whatever runs inside the frame is the researcher's responsibility: Carrier renders it, sandboxes it and records what it posts back, but validates none of it.

What the participant sees

The bindings deserve a closer look, because they are what the custom application is for. An OUT row names a new variable and Carrier creates it: a managed alias that appears in the Variables Manager locked — referenceable everywhere, editable nowhere — and is dropped again if the binding row is removed. A name already in use is refused with an inline warning rather than silently overwritten. An IN row picks from a dropdown of the experiment's variables, deliberately listing all of them rather than only those already resolved at this point in the timeline, because the interesting IN values are often ones that change during the segment — an LLM-processed variable, a running peer aggregate.

The contract on the other side of the frame is two messages. The app posts { type: 'carrier-task-data', state: {…} } whenever its state changes; Carrier picks out the OUT-bound keys, debounces them over 400 ms, discards no-op repeats and flushes whatever is pending when the segment ends. In the other direction Carrier posts carrier-variables with the changed IN keys. Variables that were already set before the segment began never fire a change event, so an app that wants them must announce itself with a carrier-app-ready message and receive the full snapshot in reply. Insert starter template writes a working skeleton that already does all of this, wired to the bindings exactly as they stand at that moment — so add the bindings first, generate the template second, and note that it overwrites any existing HTML without asking.

A task can run standalone or embedded, and both embedded layouts are fully supported: the inline card rewires the submit, iframe and custom-application listeners exactly as the standalone path does. The defaults are standalone and inline. The split layout — the app in the main pane with a live chat docked beside it — is the intended shape for an instrument used during a discussion, but it needs a chat segment as its parent; without one it falls back to the inline card silently. Below 900 px of viewport width every embedded segment reverts to standalone, which for a task means the app replaces the conversation rather than sitting next to it.

§2 · Segments

2.18 The process segment

A process segment shows a spinning icon and a single line of text — by default “Analyzing your responses…” — centred on an otherwise empty screen. There is no input, no Continue button, and no navigation of any kind: the participant waits, and the platform moves them on when it is ready. It is the only segment type that asks nothing at all of the person in front of it.

Its purpose is the work happening out of sight. While the spinner turns, the server runs the llm-processed variables attached to the segment: it sends the sources those variables declare — a free-text answer, an earlier submission, a chat transcript — to a language model with the researcher's prompt, and stores the result against each participant. A process segment is therefore the join between something a participant has already done and something a later segment needs to know: a summary of an open-ended answer to read back to them, a classified stance used to gate a chamber, a piece of advice written into an instruction. It is plumbing rather than an activity, and it exists for one reason — the timeline must not advance until that derived value exists.

What the participant sees

Everything about the language-model call itself — provider, model, system and user prompts, declared sources, output format, and whether the call is made once per participant or once per chamber — belongs to the variable definition in the Variables manager (§4.2), not to the segment. The segment contributes only three things: when the call happens, how long the study will wait for it, and what the participant sees meanwhile. One consequence is worth knowing before debugging an empty result: if a ticked variable carries a capture scope pointing at some other chamber or segment, the process segment skips it silently and its stored value stays frozen.

The builder's validation panel flags a process segment with nothing ticked (“nothing will be processed”), and flags a tick that no longer corresponds to an existing llm-processed variable — renaming or deleting a variable in the Variables manager leaves the segment holding a dangling reference, which is reported but not repaired.

2.18.1 Display and timing

Treat the process segment as standalone only. The builder's Display & Sharing card nonetheless offers it a Standalone / Embedded choice, because embedding is withheld only from chat and attention-check; the participant-side renderer, however, has no case for this type. An embedded process segment renders the literal text “Unknown segment type: process” inside the chat flow and the variables never run at all. (Below a 900 px viewport the runtime falls back to standalone and the segment works by accident, which makes the fault easy to miss on a laptop.) Leave Display Mode alone. There is no Data Sharing control, since nothing is submitted here.

Timing is collective. The server starts the run only once every participant in the chamber has reached the segment, and broadcasts completion to the whole chatroom, so a matched group waits together and leaves together. In a single-participant chamber the wait is simply the length of the call.

§2 · Segments

2.19 The attention-check segment

An attention-check segment takes over the screen with a panel headed “Attention Verification” and asks the participant to prove they are present and paying attention before the timeline will let them continue. What that proof looks like depends on the mode. In survey mode the panel is a short Survey.js form of researcher-written items — instructional-manipulation checks, catch trials, comprehension questions — graded the moment the participant presses Survey.js’s own Complete button. In liveness mode the participant first sees a consent-style pre-screen (“This step requires camera access to verify your presence” / “No video will be recorded or transmitted”) with a Begin Verification button, then a live camera preview that calibrates, waits for a face to hold steady in frame behind a filling progress bar, and finally requests one physical action at a time — blink, turn left, raise eyebrows, and so on. In CAPTCHA mode the participant meets an animated canvas and a countdown: either counting circles in a phase-coded animation, clicking a red dot before it vanishes, or watching a masked ball trace a hidden path and then picking every matching trajectory out of a thumbnail grid.

The purpose is screening, and the segment is built around what happens to a participant who fails rather than around the check itself. Every attempt emits a result record — mode, pass/fail, retry count, and mode-specific details — which lands both on the run and as a system message interleaved into the transcript, so a failure is visible in the export at the moment it happened (see §6.5). The failure itself routes through a configurable policy: end the session with a message and a redirect to a panel screen-out URL, grant a fixed number of retries, or log the failure and carry on so that attentiveness can be used as a covariate rather than an exclusion. The three CAPTCHA variants exist for a narrower reason: their answers are generated and graded server-side, so unlike a survey item they cannot be passed by a script that has read the experiment configuration.

2.19.1 Mode

Mode is the first control on the panel and selects the whole check family — Survey (question-based) (the default), Liveness (camera-based), or CAPTCHA (perception / reaction). Changing it rebuilds the rest of the panel, but the configuration for all three families is kept side by side in the segment, so switching mode to look at the other options does not discard the settings already entered.

2.19.2 Survey mode

What the participant sees

2.19.3 Liveness mode

Liveness mode has two phases in two accordions, each independently switchable. The presence phase establishes that a face is in front of the camera at all; the liveness phase establishes that it is a live one by requesting actions a static photograph cannot perform.

A camera permission the participant declines is treated as a retryable problem, not a failure: the panel shows a warning and offers another attempt rather than terminating the run. A passing liveness check is also the only thing that can start a chamber’s Background Face Monitoring — that setting’s Start After Segment dropdown lists attention-check segments and nothing else (see §1.3).

2.19.4 CAPTCHA mode

CAPTCHA Variant selects one of three challenges, each with its own parameter set and its own server-side grader. Changing the variant rebuilds the sub-panel.

2.19.5 What happens on failure

These controls sit below the mode-specific panel and apply to all three modes identically.

2.19.6 Display mode and timing

The attention check is standalone only, and this is enforced on both sides. The builder never offers a Display Mode dropdown for this type — its Display & Sharing card is empty, with no embedded-start triggers and no data-sharing control — and the runtime has no embedded renderer for it, so it can never be layered over a chat. That is a deliberate constraint rather than an omission: an attention check that could be dismissed like an overlay, or answered while a conversation continued underneath it, would not be measuring attention. The two common timing fields, however, behave differently here than anywhere else, and both are worth setting explicitly.

Roles — who occupies the slots a chamber defines, and what each kind of occupant may do inside these activities — are the subject of §3.

§3 · Roles

3.1 Why roles exist

Chapter 1 defined the shape of an experiment but not its cast. A chamber declares a list of slots, each of which awaits a participant; the question this chapter answers is what a participant who fills a slot can actually do.

Carrier separates that question into two orthogonal axes:

• The type of a participant — what they are. Four types: a real human, an LLM chatbot (language-model-driven, chat only), a scripted chatbot (rule-driven, chat only), or an agent (an autonomous Claude Agent with built-in tools for reading documents, running code, and browsing the web — see the note on non-human participants).
• The role of a participant — how they take part. Three roles: a communicator, a mediator, or a processor.

The four kinds of participant differ in two practical respects — how they produce what they say, and how reproducible they are across sessions:

The type × role matrix is the most important table in this chapter, because almost every design decision below either depends on it or is constrained by it:

The only forbidden combination is scripted chatbot as processor. The reason is technical but worth knowing: processors operate by reading drafts, generating suggestions, or interrupting composition — activities that demand the kind of open-ended language understanding only a human or a language model can provide. A pre-scripted rule set has no business being a processor.

Everything else is supported. That makes it possible to write one experimental design and instantiate the same role with a human in one condition and a language model in another — which is the single most important affordance Carrier offers for studies that compare human and machine behaviour. It also means that the choice between an LLM chatbot, a scripted chatbot, and an agent can itself be the manipulation: same role, same instructions, three different kinds of non-human partner — one talking from training-time knowledge, one talking from a written rulebook, one talking from documents it has just read.

§3 · Roles

3.2 The spatial model: three zones in the interface

A useful way to keep the roles separate in your mind is to remember that each occupies a distinct zone of the participant's screen during a chat segment:

This is more than visual hygiene. Mediators broadcast; communicators converse; processors assist composition before words enter the conversation. The separation of channel is what makes it possible to study facilitation, conversation, and composition assistance independently of one another — or to combine them deliberately, knowing that the layers do not bleed into each other.

§3 · Roles

3.3 Communicator

3.3.1 Framing

The communicator is the primary interactive participant. Whatever the experiment ultimately studies, communicators are the ones doing the studied behaviour. All communicators — whether a human, an LLM chatbot, a scripted chatbot, or an agent — operate in the same message space: their messages appear in the main chat area alongside each other in the order they were sent.

The animating design principle is interaction parity. A human communicator and any non-human communicator send messages through the same mechanism, appear in the same UI, and are indistinguishable to other participants unless the researcher explicitly marks them otherwise. This is what makes it possible to run human–human, human–machine, and machine–machine conditions of the same design without rebuilding the experiment.

3.3.2 The communicator design surface

Three dimensions of configuration matter for any communicator. They are independent: settings on one dimension do not constrain settings on the others.

Identity. Who appears in the chat, by what name, and with what disclosure?

Human communicators typically go through an identity-setup flow (choose a display name, pick an avatar) before entering the experiment. Non-human communicators — LLM chatbots, scripted chatbots, and agents alike — carry pre-configured identities. The separation makes blinding possible: a participant cannot tell from the interface alone whether a fellow communicator is human or a machine.

Input control. When can the communicator speak, and who decides?

Carrier's chat input is not simply on or off. A communicator might begin with input disabled, wait for three messages from other participants, and then become enabled. Or a mediator (see §3.4) might disable and re-enable input on the fly to enforce turn-taking. Building experimental conditions out of these primitives is how you produce interventions like simultaneous discussion vs. sequential discussion.

Message capabilities. What kinds of messages can be sent and acted on?

3.3.3 Communicator subtypes at a glance

The four communicator subtypes correspond to the four types in the matrix:

• Human communicator. A real participant joining via browser. They enter the matching queue, are matched into a chamber, and join its chatroom. The platform tracks their socket connection with a heartbeat; on disconnect they can be reconnected within the session. All messages, survey responses, timestamps, and activity events are recorded.
• LLM-chatbot communicator. Configured by provider (OpenAI / Anthropic / Google / compatible), model, system prompt, temperature, and response logic (when to speak, when to stay silent — see §5.3). The model is given the conversation so far on each turn and produces a chat message (or stays silent). LLM chatbots never enter the matching queue: once the human slots in a chamber are filled, they are spawned into the chatroom automatically. The platform supports multi-step LLM chains for advanced configurations (a generation step, then a critique step, then a rewrite step).
• Scripted-chatbot communicator. Configured by a set of triggers (§5). Like LLM chatbots, scripted chatbots do not enter the matching queue — they are spawned into the chatroom after human slots are filled. Their behaviour is deterministic and replayable: the same input sequence produces the same outputs across sessions, which makes them the right choice for confederate roles and any design in which conversational reproducibility matters.
• Agent communicator. A Claude Agent (Anthropic) scoped to a particular document area — typically the study materials, a reference corpus, or a configured dataset. Before producing each message, the agent's underlying model loops over its built-in tools (file reading, code execution, web browsing) to look things up, run small computations, or check a citation. The message it eventually sends is grounded in what it has retrieved. Agent communicators are the natural choice when the experiment wants a conversational partner that can answer with evidence — a study-materials expert that quotes the brief verbatim, a fact-checker that can browse during the discussion, a domain assistant that can re-read the dataset before stating a number.

3.3.4 Research uses of the communicator role

A short, indicative list of designs that map cleanly onto different communicator configurations:

§3 · Roles

3.4 Mediator

3.4.1 Framing

The mediator is a facilitator. Unlike a communicator, a mediator does not converse on equal footing with the others — they orchestrate the conversation. The qualitative differences are four:

1. Universal visibility. A mediator sees every message in the chat, regardless of who it was addressed to.
2. Distinct delivery. A mediator's output appears as styled announcements at the top of the chat, not as chat bubbles.
3. Control capabilities. A mediator can act on the chat — disable a communicator's input, prompt a specific participant, highlight a message — not only speak into it.
4. Event awareness. A mediator reacts to aggregate patterns (number of messages, time elapsed, idle participants) at least as readily as to individual messages.

These four capabilities together describe the moderator / facilitator / researcher dynamic that has no analogue in plain group chat.

3.4.2 The broadcast system

Mediator messages are called broadcasts. A broadcast is styled along three independent axes:

Broadcasts can also be targeted: at every participant in the chamber, at communicators only, at a specific named participant, or at all participants in a specific role. This is the mechanism by which a mediator can deliver a private prompt to one communicator without the rest of the group seeing it.

3.4.3 Facilitation actions (LLM-driven mediators)

When the mediator is driven by a language model — either an LLM chatbot or a Claude Agent — it has access to an action vocabulary that goes beyond plain broadcasting. These five intervention actions are produced as part of the model's structured response on each turn; the most consequential is the first.

A mediator implemented as a scripted chatbot can fire the same actions, but their parameters must be baked into the trigger configuration ahead of time (§5.5); the scripted bot cannot choose the action contextually based on what was just said.

Note that this intervention-action vocabulary — disable_chat, enable_chat, prompt_participant, highlight_message, request_attention — is distinct from the built-in tools of a Claude Agent (file reading, code execution, web browsing). They live on different channels:

• The intervention actions are how a mediator acts on the chat — they affect what participants see and what they are allowed to do.
• An agent's built-in tools are how it gathers information for itself — they affect what the agent knows when it speaks, but the participants see only the eventual message.

A Claude Agent acting as mediator has access to both: it can read its configured document area before responding, and fire intervention actions alongside its broadcast. An LLM chatbot acting as mediator has only the intervention actions; a scripted chatbot acting as mediator has only the pre-baked variants.

The disable_chat action supports composite release conditions — a list of conditions combined with an any / all connector that determines when the disable lifts. The available conditions are:

• Timeout — after a fixed duration.
• All others responded — when every other communicator has sent a message of at least a configured minimum length.
• Message count — after a fixed total number of messages have been sent in the chat.
• Keyword mentioned — when a designated keyword (or any from a list) is uttered by any, or a specific, participant.
• Participant message — when a designated participant has sent a configured number of messages.
• Mediator release — released only by an explicit subsequent enable_chat.
• Segment change — released when the chamber transitions to its next segment.

Composite release conditions are the building blocks for richly specified turn-taking protocols. “Wait until everyone else has responded, or sixty seconds, whichever comes first” is a single disable_chat action with two conditions and an any connector.

3.4.4 Mediator-specific triggers

Mediators inherit the standard trigger system (§5), but five extra trigger types are particularly suited to facilitation:

These trigger types, combined with the action vocabulary above, are what make automated AI facilitation in Carrier expressive: a mediator can be configured to periodically summarise the discussion every two minutes, prompt any participant who has been silent for ninety seconds, or steer the conversation back on topic when a specified keyword has not appeared in the last thirty messages.

3.4.5 Activity monitoring

A mediator can optionally maintain an activity model of each communicator. The activity-monitor settings are:

• An idle threshold (milliseconds of inactivity before a participant is considered idle), and a list of idle prompts to send when it is reached.
• An active threshold (messages-per-minute rate at which a participant is considered to be dominating), and a list of active prompts to send when it is reached.

This is the building block for participation-equity interventions: a mediator that automatically prompts quiet members and gently invites dominant members to “make space for others”.

3.4.6 Research uses of the mediator role

§3 · Roles

3.5 Processor

3.5.1 Framing

The processor is the most novel of the three roles. It operates in the input composition space rather than the message exchange space — that is, it acts before a communicator's text becomes a message in the chat. Where a mediator sits over the conversation and a communicator sits inside it, a processor sits alongside the input box, reviewing what the communicator is about to send, generating drafts on request, or offering live suggestions as the communicator types.

The role exists because the act of composing a message is a distinct site of intervention — distinct from facilitating the conversation, and distinct from participating in it. A study that wants to ask “what happens when an AI helps people write what they say?” needs a place to put that AI, and that place is not the chat.

3.5.2 The design space, in three dimensions

It is tempting to think of processors in terms of “review” and “generate” alone, but the design space is richer. Three independent dimensions structure it.

Initiation. Who starts an interaction?

• Communicator-initiated — the communicator explicitly asks (submits a draft for review, clicks Generate).
• Processor-initiated — the processor offers help without being asked (sends a suggestion).
• System-initiated — the platform triggers an interaction based on an event (a pause is detected, a timer elapses).

Control. Who controls the final output?

• Communicator retains control — the communicator always decides what is actually sent (accept / reject / edit the processor's output).
• Processor retains control — the processor decides what the communicator sees (filtering, rewriting).
• Shared control — both can edit; the final version is negotiated.

Timing. When does the interaction happen?

• Pre-send — before the message enters the chat (review, approval).
• During composition — while the communicator is typing (real-time suggestions).
• On-demand — when explicitly requested (a Generate button).

Not every combination of these dimensions is feasible. LLM API latency makes true simultaneous co-editing impractical for LLM processors; processor-controlled rewriting risks undermining the validity of self-report studies by replacing the communicator's voice with the processor's. Carrier's design therefore commits to one principle and offers three concrete modes.

The committed principle: communicator agency. Whatever the processor does, the communicator retains final control over what enters the chat. The processor never bypasses the communicator's agency.

3.5.3 The three modes

Review

Communicator writes draft  →  submits for review  →  processor gives feedback
                                                     ↓
Communicator accepts / edits / rejects  →  message sent to chat

Configuration parameters:

• Trigger — on-submit (the communicator clicks Send and the processor steps in) or pause-triggered (the processor steps in automatically after the communicator stops typing for a configured period).
• Pause timeout — the inactivity window, in milliseconds, used only when the trigger is pause-triggered.
• Feedback format — freeform (the processor writes a free-text response), inline-edit (the processor proposes an edited version of the draft), or approve-reject (the processor returns a binary verdict).
• Mandatory — whether the communicator must address the feedback before they can send the message.
• Max rounds — a cap on the number of review iterations on a single draft.

Research applications include writing-quality improvement, self-reflection, metacognitive scaffolding, and peer-review dynamics.

Generate

Communicator clicks Generate  →  processor creates a draft
                                  ↓
Communicator edits  →  message sent to chat

Research applications include AI-ghostwriting perception, co-authoring dynamics, and the trade-off between generation quality and editing effort.

Real-time assist (human processors only)

Communicator types  →  the draft streams to a human processor
                       ↓
Processor sends ephemeral suggestions  →  communicator accepts or dismisses

This mode is restricted to human processors because LLM round-trip latency makes truly live suggestions impractical. The use cases — peer coaching, expertise-based assistance, live mentoring during composition — all assume a human partner at the other end.

3.5.4 Phase scripts: dynamic processor behaviour

A processor does not have to behave the same way throughout a chamber. Carrier supports phase scripts — an ordered list of phases, each with a mode and a transition trigger that advances to the next phase.

phases: [
    { id: "warmup",     mode: "disabled", transition: { on-start } }
    { id: "review",     mode: "review",   transition: { message-count: 5 } }
    { id: "generate",   mode: "generate", transition: { time-elapsed: 180000 } }
]

The processor in this example starts disabled, switches into review mode once five messages have been exchanged, and switches into generate mode three minutes after the segment starts. The supported transition trigger types are:

Phase scripts are how Carrier supports designs like progressive scaffolding (start with heavy review, then withdraw assistance over time) or adaptive intervention (switch modes once a quality threshold has been crossed).

3.5.5 Context configuration

The amount of conversation a processor can see is configurable:

For LLM processors, the context level controls what is sent to the model with each call. For human processors, it controls the contents of a read-only chat panel beside the suggestion interface. Context level interacts with privacy considerations: a research design that does not want the processor influenced by — or able to see — earlier conversation should set context to none.

3.5.6 Research uses of the processor role

§3 · Roles

3.6 How the roles interact

The three roles are designed to be orthogonal — to operate in different spatial zones, on different inputs, with different output channels — but they can be present in the same chamber and combined in principled ways.

Communicator ↔ mediator. Asymmetric. The mediator sees everything; the communicator does not see the mediator's view. The mediator can broadcast to communicators, disable or enable their input, prompt them privately, and highlight their messages. This asymmetry is intentional: it models the moderator dynamic.

Communicator ↔ processor. Collaborative but communicator-controlled. The processor sees drafts; it sends feedback, suggestions, or generated text; the communicator decides what actually gets sent. The processor never bypasses the communicator.

Mediator ↔ processor. Orthogonal. Mediators act in the broadcast/control layer; processors act in the composition layer. They do not directly interact, but their effects can be coordinated — a mediator might broadcast that “the next message will be reviewed” at the same trigger point at which a processor switches from disabled to review mode.

Four representative configurations to keep in mind:

§3 · Roles

3.7 Design principles, distilled

Six principles run through the role system. They are summarised here for reference.

1. Separation of concerns. Each role occupies a distinct spatial zone (chat, broadcast, input) and serves a distinct function (communicate, facilitate, assist). The separation is what enables clean experimental contrasts.
2. Communicator agency. The communicator always retains final control over what they say. No mediator or processor can speak in their name.
3. Type orthogonality. Any participant type that is compatible with a role can fill it. This is what makes human–AI comparisons trivial to set up.
4. Phase-based dynamism. Both mediators (via triggers) and processors (via phase scripts) can change behaviour during a session, enabling within-session manipulations and progressive designs.
5. Comprehensive logging. All messages, broadcasts, mediator actions, and processor interactions are recorded with metadata. This is what makes the resulting data analysable.
6. Configuration hierarchy. Global → chamber → segment overrides → event-based control. Defaults at the top, specificity at the bottom.

§3 · Roles

3.8 Builder walkthroughs

Variables — the attributes that travel with each participant and decide which slots they can fill, which chambers they see, and what each activity says to them — are the subject of §4.

§4 · Variables

4.1 Why variables exist

By the end of Chapter 2 we have a design that can place a researcher's chosen mixture of humans, LLM chatbots, scripted chatbots, and agents inside a sequence of chambers, with each role doing what the design expects. That design is, however, still impersonal: it treats every participant identically. The same chamberline, the same slots, the same instructions, the same prompts — applied to every person who walks into the experiment.

Variables are how a Carrier experiment becomes personal. A variable is an attribute attached to a participant — their self-identified expertise, the political party they support, the score they obtained on the pre-survey, the option they ranked first in the last chamber — that is then available to the rest of the experiment to consult. Variables let you:

• Constrain matching. Require that the matched group contain (say) one self-identified novice and one self-identified expert.
• Gate visibility. Show a remedial chamber only to participants whose pre-test score was below threshold; skip the chamber for everyone else.
• Inject context into instructions and prompts. Address each participant by their chosen name; brief an LLM mediator on the political identification of each person in the room.
• Drive triggers (§5). Fire a bot's response only when the variable matches a condition.

In conventional methodological language, variables are how Carrier represents the experimentally-relevant measured and manipulated characteristics of each participant. Once captured, they travel with the participant for the rest of the run.

§4 · Variables

4.2 The anatomy of a variable

A variable is defined once, at the experiment level, and then referenced from anywhere in the experiment. Each definition has the following parts:

Variables are addressed in the rest of the experiment by their key, prefixed with var. — for example, var.expertise or var.party_id. The prefix exists so that the system can tell, when reading a configuration, that a string is referring to a variable rather than to a literal.

4.2.1 Where variable values come from

A variable's value is computed from a source specification. The five common sources are:

• Survey response. The most common source. Read the value of a named question from one of the participant's completed surveys — the global pre-survey, a chamber pre- or post-survey, or any embedded survey segment. Survey-based variables are evaluated as soon as the survey is submitted, which means they are available for chamberline assignment, slot matching, and chamber visibility from that point forward.
• Segment submission. Read what the participant submitted during a particular segment — the option they chose in a selection segment, the order they produced in a ranking segment, the text they entered in an input segment. A submission from a segment embedded in a chat is available during that chat (the embedded card runs alongside it): triggers and prompts in the parent chat can read it, but the value is empty until the participant actually submits, and the builder's pickers flag such variables as “available during segment”.
• Segment data. Read data captured about a segment — how long the participant spent, how many messages they sent, whether they passed an attention check.
• System-assigned. Read a value the platform sets automatically — the chamberline the participant was assigned to, their participant ID, the run identifier.
• Aggregate. Compute a value across multiple participants — the mean of all communicators' pre-test scores in the same chamber, for example, or the modal political identification of the group. Aggregates are how a configuration can talk about the group, not just the individual.

A source can be qualified by a participant reference: by default a variable is read from the participant who is being configured (referred to internally as self), but it can also be read from another slot in the chamber (slot:1, slot:2, or slot:mediator). This is what makes it possible to address a fellow participant in an instruction or in a system prompt — for example: “you are about to chat with {slot:1:var.first_name}, who identifies as a {slot:1:var.party_id} voter.”

4.2.2 Per-option numeric values

A choice-type variable is, by default, a categorical label — “novice” or “expert”, “Democrat” or “Republican”. When a numerical contrast is also useful, each option in the variable's definition can carry an associated numeric value.

A typical case is a five-point self-rating scale. The variable's options might be labelled Very low / Low / Moderate / High / Very high, with numeric values 1 / 2 / 3 / 4 / 5. The label is what the participant sees and what is logged in raw form; the numeric value is what the configuration arithmetic uses when computing aggregates or threshold conditions. A condition like “this chamber only appears if the participant's expertise is ≥ 3” is expressed against the numeric value, not the label.

Numeric values are optional. A variable without them behaves as a pure categorical attribute.

4.2.3 Aggregate variables across non-human participants

When an aggregate variable is computed across the participants of a chamber, the researcher can choose whether non-human participants (LLM chatbots, scripted chatbots, and agents) are included or excluded from the aggregate. This setting matters in two common situations:

• Confederated designs (one human, several non-human communicators) — usually the researcher wants aggregates to reflect humans only, since the non-humans are confederates.
• Group-property analyses (e.g. mean expertise of the room) — the researcher chooses whether non-human participants carry an expertise value at all, and whether it contributes to the mean.

The default is to include only humans in aggregates; the alternative is configured on each aggregate variable definition. The same humans-only / include-all toggle applies regardless of which of the three non-human kinds is present in the chamber.

§4 · Variables

4.3 Variables as matching constraints

The first place a variable does work is during matching. There are three places in the configuration where a variable can constrain who is matched into what:

4.3.1 Chamberline eligibility

A chamberline can declare a filter — a condition expressed against variables that a participant must satisfy in order to be eligible for that chamberline. When the experiment's chamberline-assignment method is survey-based (see §1.2.2), the filter is the mechanism by which the assignment is made:

Chamberline "Pro-disclosure"   filter:  var.party_id == "Democrat"
Chamberline "Anti-disclosure"  filter:  var.party_id == "Republican"

A participant whose var.party_id is Democrat will be eligible for the first chamberline and not the second; the inverse holds for Republican participants. Participants who do not satisfy any chamberline filter are routed to a default chamberline if one exists, or terminated gracefully otherwise.

4.3.2 Slot requirements

Inside a chamber, each slot can declare a list of required properties — conditions that the participant filling the slot must satisfy. A two-slot chamber with the slot constraints

Slot 1   human communicator   requires:  var.expertise <= 2
Slot 2   human communicator   requires:  var.expertise >= 4

will pair each session into one novice and one expert. Matching does not begin for this chamber until two participants are waiting who jointly satisfy the slot constraints — a queued participant whose expertise is 2 can be matched into Slot 1, and a queued participant whose expertise is 5 can be matched into Slot 2, but two novices cannot fill the chamber on their own.

Slot requirements can reference any variable that has been resolved by the time the chamber begins. In practice this means anything captured in the global pre-survey, anything assigned by the system, and anything from earlier chambers in the participant's run.

4.3.3 Building one: a variable that assigns the pairing

The whole journey, in the builder, end to end. A counterbalance variable with two values is defined once, and each of the chamber’s two human slots then requires one of them. From that point matching will only seat a participant where their value fits, so every pair is one of each — and because the variable is counterbalance rather than random-pick, the draw leans toward whichever side is short.

Three things in that recording are worth naming. The kind picker is where the eight kinds are chosen, and each card carries the one-line description of what that kind does — the documentation sits on the control rather than in a panel beside it. The slot’s Required Properties key field is a picker of the variables that resolve at that position, not a free-text box; a variable that is not yet available there is listed with the reason. And once the slots are wired, the variable’s own Used in panel reports gates 2 match slots in 1 chamber, so the dependency is visible from both ends.

To run it yourself: npm run demo:matching seeds the fixture and starts the app; npx playwright test e2e/matching-variable.spec.js walks it in a browser, checks what reached the database, and rebuilds the clip above.

4.3.4 Group-composition constraints

Slot-by-slot constraints are sometimes too weak to express a desired group property. Where the slot constraints care only about who fills each seat, a group-composition constraint cares about a property of the matched set as a whole. Typical examples:

• The chamber requires a gender-balanced trio — at least one male, at least one female, no constraint on the third seat.
• The chamber requires that the modal political identification of the trio is Democrat.
• The chamber requires that no two members share the same self-reported expertise level.

Group-composition constraints are expressed against aggregate variables (3.2.3) and are evaluated against the candidate set during matching. A candidate matching is admitted only if the corresponding aggregate, computed over the candidates, satisfies the constraint.

§4 · Variables

4.4 Variables as visibility gates

A second use of variables is to gate what a participant sees, not just who they see it with. A chamber can declare a visibility condition against one or more variables. The chamber is included in the participant's run only if the condition is true at the moment the chamberline would otherwise enter that chamber.

This is the canonical mechanism for branching designs:

• A practice chamber that is shown only to participants whose pre-test score was below threshold.
• A debriefing chamber for the high-anonymity condition that does not exist in the low-anonymity condition (an alternative to two parallel chamberlines, useful when most of the experiment is identical between conditions).
• A post-task survey that is shown only to participants who actually completed the preceding chat (skipped for those whose chamber was terminated early).

Visibility conditions take the same form as slot constraints: a boolean expression against variable values, with the standard comparison operators and any / all connectors. Crucially, visibility is evaluated just before the chamber would begin, not once at the start of the run. This means that variables produced during the run — by an earlier chamber's segment submission, by a chamber post-survey — are usable as gating conditions for later chambers.

When a chamber is gated out for a participant, the participant skips directly to the next chamber in their chamberline. The chamberline itself does not change.

4.4.1 Slot requirements vs visibility conditions

A natural question at this point: a chamber whose every slot has a requires constraint already excludes participants who cannot fill any seat — they will never be matched. Why, then, does Carrier also offer a separate visibility condition at the chamber level? Don't they do the same job?

They overlap in one specific case and diverge in the others. The rule that governs the overlap is:

Implicit skip rule. If every human slot in a chamber has a non-empty requires constraint, and the participant satisfies no slot's constraint, then the chamber is silently skipped for that participant — exactly as if it had a failing visibility condition.

The skip is implicit: there is no separate visibility expression to write. The chamber is treated as not part of the participant's run, and they advance to the next chamber. This is what you observed.

Three scenarios make the distinction concrete.

Scenario A — Single fully-constrained slot. A solo-participant chamber whose one human slot requires var.condition == "treatment". A control-condition participant cannot fill it; the implicit skip rule fires; the participant moves to the next chamber. Here, slot requirements alone are sufficient — adding a chamber-level visibility condition would be redundant.

Scenario B — Mixed open and constrained slots. A two-slot chamber where one slot requires var.role == "expert" and the other slot has no constraint:

Slot 1   human communicator   requires:  var.role == "expert"
Slot 2   human communicator   requires:  (none)

A novice participant can fill Slot 2, so the implicit skip rule does not fire — the chamber is visible to them, and they will join it paired with an expert. If you intended this — “novices and experts meet here, with the expert always seated in Slot 1” — that is the correct behaviour and you should add nothing further. But if you intended the chamber to exist only for experts (with Slot 2 reserved for another expert who happens to be unconstrained because of how you defined the slot), the implicit skip rule will not save you. A novice will silently enter. To get a true gate here, add a chamber-level visibility condition var.role == "expert". Slot requirements cannot express this on their own.

Scenario C — Chamber-level gate plus slot-level role assignment. A debriefing chamber that should exist only for participants who completed a treatment chamber upstream, and within that chamber should pair a “writer” participant with a “reviewer” participant:

Chamber "Debrief"
   visible if:  var.completed_treatment == true
   Slot 1   human communicator   requires:  var.debrief_role == "writer"
   Slot 2   human communicator   requires:  var.debrief_role == "reviewer"

Both layers are necessary. The chamber-level visibility expresses who belongs in this chamber at all; the slot requirements express which seat each participant takes once they are here. Trying to collapse the gate into a slot constraint (for example, by adding var.completed_treatment == true to both slots' requires) works only by coincidence — the implicit skip rule fires because every slot is constrained — and it conflates two distinct intents. If a future edit relaxes Slot 2's requires to allow walk-ins, the chamber suddenly becomes visible to participants who never completed the treatment, and the gate is silently gone.

This last point is the deeper reason the two systems are kept separate. Visibility conditions express intent explicitly; slot requirements express it emergently. When the only way a chamber is skipped is “all slots happen to be constrained and the participant happens to satisfy none,” that skip is a side effect of a configuration that was written for a different reason. Edits to the slots — adding a slot, opening one up, retitling roles — can quietly remove the gate. An explicit visibility condition survives those edits and is auditable as a routing rule on its own.

A compact way to choose between them:

In short: when slot requirements happen to act as a gate, treat that as a convenient side effect, not as the gate itself. If the chamber is meant to be conditional on a participant property, say so with a visibility condition.

§4 · Variables

4.5 Variables in instructions and prompts

The third use of variables is the most pervasive: interpolation into the natural-language content shown to or used by participants. Any place in the experiment where text is shown to a participant or sent to an AI is also a place where variables can be injected.

The interpolation syntax is {{var.<key>}} for a variable read from the current participant, and {{slot:<n>:var.<key>}} or {{slot:<role>:var.<key>}} for a variable read from a fellow slot. A few worked examples:

Instruction segment text

Welcome, {{var.first_name}}. In the next ten minutes you will discuss
climate policy with two other participants. The participant on your
left has expertise level "{{slot:1:var.expertise_label}}"; the
participant on your right has expertise level
"{{slot:2:var.expertise_label}}".

System prompt for an LLM mediator

You are facilitating a discussion among three participants. Their
self-identified political positions are: {{slot:1:var.party_label}},
{{slot:2:var.party_label}}, and {{slot:3:var.party_label}}. Adjust
your tone to be welcoming to all three positions; do not take sides.

Survey question stem

Earlier you said your most important consideration was
"{{var.top_value}}". On the slider below, indicate how strongly you
still feel that this is your most important consideration.

Two things to note. First, interpolation happens at the moment the text is needed — the same instruction segment used in a chamber that appears twice will be re-interpolated each time, with the latest variable values. Second, an undefined variable interpolates to the empty string by default, but the variable definition's default field can be used to specify a fallback. Where it matters, configure a default.

4.5.1 Per-option text vs per-option value in interpolation

Recall that a choice-type variable can carry both a label and a numeric value for each option (3.2.2). When interpolating into text, two conventions matter:

• {{var.expertise}} interpolates the key of the chosen option (“low”, “moderate”, “high”).
• {{var.expertise_label}} interpolates the display label of the chosen option (“Low”, “Moderate”, “High”).
• {{var.expertise_value}} interpolates the numeric value of the chosen option (e.g. 2, 3, 4).

For a five-point Likert variable, the three forms give you the same information at three different levels of formality. Choose by context: instructions to participants benefit from the display label; an LLM system prompt typically benefits from the numeric value or the key.

§4 · Variables

4.6 Variables in trigger conditions

A fourth use of variables is in trigger conditions (§5): a bot's keyword trigger, time trigger, or message-count trigger can be qualified by a check on a variable. This makes triggers conditional on participant attributes — a bot might only respond to keyword “X” if slot:1:var.condition is “treatment”, for example. The full mechanics of trigger conditions are covered in §5.2; here it is enough to know that the same var.<key> references work inside trigger conditions as work elsewhere.

§4 · Variables

4.7 Builder walkthroughs

Triggers — the rule system that drives the behaviour of every non-human participant in the experiment, the final piece of the four-system picture — are the subject of §5.

§5 · Triggers

5.1 Why triggers exist

The previous three chapters answered the questions what shape is the experiment, who is in it, and what do we know about them. They left one question open: how do the non-human participants behave? A scripted chatbot, an LLM chatbot, and an agent are all just slots in a chamber until something tells them when to speak and what to say.

That “something” is the trigger system. A trigger is a rule that combines:

• A condition — what has to be true before the trigger fires.
• A response — what the bot says if the trigger fires.
• Optionally, an action — what else the bot does if the trigger fires (disable a participant's input, prompt a specific person, transition the chamber, and so on).

You can think of a non-human participant's configuration as a book of rules: an ordered list of triggers, each with a condition–response–action triple. When something happens in the chamber, Carrier consults the book in order, evaluates the conditions against the current state of the chat, and fires the rules that match. This applies equally to deterministic scripted chatbots (whose responses are pre-written sentences), to LLM chatbots (whose responses are generated by a language model on the fly), and to agents (whose responses are generated by a language model that has consulted its tools first).

A useful analogy from the methods literature: a trigger is to an interactive bot what a confederate script is to a confederate participant — a list of contingent rules that say “when X happens, do Y”. Carrier's contribution is to make the list expressive enough to capture the contingencies real conversations contain, and machine-readable enough to be replayed identically across sessions.

§5 · Triggers

5.2 The trigger model: condition → response → action

A single trigger has the structure:

The next three sections expand each of these three parts. The modifiers are covered together in §5.6.

§5 · Triggers

5.3 Conditions: when a trigger fires

The condition of a trigger is the part most worth understanding well, because it determines whether the rule ever runs. Carrier supports a catalogue of condition types organised by what they listen for: message content, time, message counts, sequences, participant events, and aggregate states.

5.3.1 The catalogue of condition types

Two practical notes:

• Most of these conditions presuppose a chat segment. Keyword, regex, message-count, sequence, and the mediator-only message conditions all listen to the conversation; if the chamber is currently in a slide or a survey segment, they are silent. Time and participant-action conditions, by contrast, can fire from any segment.
• The mediator-only types (periodic, aggregate, topic-detected, activity-timeout, participant-count, discussion-phase) are enforced as mediator-only by both the builder and the runtime. The builder hides them from non-mediator agents' trigger pickers, and the runtime only initialises and evaluates them for bots with role === 'mediator'. Attaching one of these types to a communicator or processor (e.g., by hand-editing the JSON) will silently never fire.

5.3.2 Modifiers shared by all condition types

Every trigger, whatever its condition type, can be qualified by a small set of modifiers:

The variable filter is especially powerful in combination with §4: a single set of triggers, attached to a single bot template, can produce qualitatively different behaviours in different chamberlines purely on the basis of the variables that are true of the participants in front of it.

5.3.3 An aside: triggers, segments, and the “active segment” filter

Most trigger configurations include an active-segments filter — a list of segment IDs (within the chamber) during which the trigger is eligible to fire. Leaving the list empty means fire in any segment. Restricting it to a specific segment — typically a chat segment — is the canonical way of writing “this rule only applies during the deliberation, not during the survey at the end”. The filter also accepts embedded child segments, which is how a trigger can be made to fire only while a particular embedded vote overlay is open.

This is a small detail, but it is the source of a very common pitfall: a trigger that “doesn't seem to fire” is often a trigger whose active-segment filter excludes the segment the chamber is actually in.

The filter has a second consequence that matters more than it looks: a time trigger's clock restarts at every segment entry. There is no chamber-wide clock. When the chamber moves into a segment, Carrier arms every time trigger scoped to that segment from zero; when the segment ends, any timer that has not yet fired is dropped. Three things follow, and each of them has bitten somebody:

• A delay longer than the segment lasts never fires. A trigger set to 12:00 in a segment that auto-advances at 10:00 arms, waits, and is discarded — silently, at run time.
• A trigger with an empty active-segments list is armed in every compatible segment, and its countdown restarts in each one. “Fire once at 30 seconds” becomes “fire at 30 seconds into each of three segments” unless Max triggers says otherwise.
• Two delays are only comparable within one segment. Ten seconds into a late segment happens after forty-five seconds into an early one, however the two numbers sort.

Idle detection keeps a different clock again: its value is measured from the last message, not from segment entry, so it is the earliest the trigger can fire rather than when it will — and in a busy chat it may never fire at all. The Timeline view (§5.6.2) draws all of this, and reports the cases that cannot work.

§5 · Triggers

5.4 Responses: what the bot says

When a trigger's condition fires, the response tells Carrier what message to send. There are two fundamentally different kinds of response.

5.4.1 Scripted responses

A scripted response is a pre-written sentence (or a list of sentences from which Carrier picks one at random). It is the only kind of response a scripted chatbot can produce, and it is also available to LLM chatbots and agents for cases in which the researcher wants exact-text control.

Configuration is minimal:

• Message — a single fixed string, or a list from which the platform draws (uniformly, by default).
• Delay — an interval before the message is actually sent, simulating typing or thought.
• Probability — the chance that the trigger fires at all when its condition is satisfied (default 1.0). Used when researcher wants stochastic intervention.

Scripted responses are deterministic: identical inputs produce identical outputs. Two participants who encounter the same conversation in the same condition will receive the same scripted response, with the same delay, in the same order. This makes them the right choice for studies in which experimental control matters more than naturalism — confederated-AI conformity studies, attention-check probes, scripted “noise” injections, and so on.

5.4.2 LLM-generated responses

The alternative is to let an LLM generate the response on the fly. A language-model response is produced by sending a request to a language-model provider (OpenAI, Anthropic, Google, or a compatible service) with a prompt assembled from:

• The system prompt of the bot (its personality, role, instructions).
• A configurable amount of chat history as context (none, the last N messages, or the full history — see §3.5.5 for the analogous setting on processors).
• Variable interpolations (§4.5) — the participant's name, condition assignment, current state.
• Optional chain steps — a sequence of LLM calls in which each step's output becomes part of the next step's input. Chains are how a single trigger can implement plan, then critique, then rewrite behaviour.

The response of an LLM-driven trigger is therefore open-ended: the model can produce any text that satisfies its prompt, modified each time by the current state of the conversation. Where scripted responses trade variation for control, LLM responses trade control for naturalism. They are the right choice for studies in which the realism of the bot's behaviour is itself part of what is being tested.

A note on the response format: Carrier's LLM responses follow a structured JSON shape with three fields — content (the message text, or null to remain silent), rationale (a brief justification, logged but not shown), and an optional actions list (the topic of §5.5). The structure exists so that the AI can decide “remain silent” without producing a blank message, and so that researchers can audit why the AI chose to speak after the fact.

5.4.3 Choosing between scripted and LLM responses

A short heuristic that holds in most studies:

The two are not mutually exclusive on a single bot. A bot template can mix scripted triggers (for greetings, attention checks, and exit messages) with LLM triggers (for the bulk of the discussion), routing each contingency through whichever response type fits best.

5.4.4 Response logic and silence

For LLM chatbots and agents, two additional configuration parameters govern when not to speak. They sit alongside the trigger list and are sometimes more important than it:

• triggerOnFirstMessage — whether the bot is allowed to make the first move (greet, open the discussion) before any human has spoken.
• respondToEveryMessage — whether the bot should attempt to respond after every incoming message, or only when one of its triggers explicitly says so.
• respondOnMention / mentionKeywords — whether the bot only responds when its name (or a configured list of keywords) appears in the chat.
• initialSalute — a configured opening message sent on chamber start, regardless of triggers.
• timeoutTrigger — a “fail-safe” prompt the bot sends after a configured silence interval if no other trigger has fired.

These five toggles, together with the trigger list, are how a researcher tells an LLM chatbot or agent the difference between a talkative configuration (“respond whenever spoken to, and also if no one has spoken for a minute”) and a reserved one (“only respond when explicitly addressed by name”).

§5 · Triggers

5.5 Actions: what else the bot does

A trigger's action field — present on every trigger, optional in most cases, central for mediators — is the side effect that fires alongside (or instead of) a response message. Actions are what allow a bot to do something to the chat rather than just in the chat.

Carrier exposes actions through four distinct mechanisms, which are easy to confuse but do different things. Read this list once before the subsections below:

The first two are about the bot acting on the chamber — they affect what participants see and what they are allowed to do. The third is about the bot acting as a participant within an interactive segment — its submission joins the humans' in the segment's results. The fourth is about the agent informing itself — it affects what the agent knows when it speaks, but its only externally visible output is still the eventual chat message. Sections 4.5.1 to 4.5.4 cover each in turn; 4.5.5 helps choose among them.

5.5.1 Scripted actions

A scripted action is an unambiguous instruction baked into the trigger configuration: “when this rule fires, disable participant X's input until either 60 s have passed or all other participants have responded, whichever comes first.” The action is part of the rule. The bot's job is to fire the trigger; the action's effect on the chat is deterministic, predictable, and visible in the configuration before the experiment runs.

Carrier's primary catalogue of scripted-action types — drawn from §3.4.3 — is:

• disable_chat — temporarily prevent a participant from sending messages, with a composite release condition.
• enable_chat — explicitly re-enable input.
• prompt_participant — send a private prompt visible only to a specific participant.
• highlight_message — visually highlight a past message for a configurable duration.
• request_attention — trigger a visual or auditory cue at a specific participant.

There are also a small number of chamber-level scripted actions used less frequently:

• advance_segment — force the chamber to move to its next segment immediately.
• terminate_chamber — end the chamber early.
• set_variable — set a variable on a participant or on the chamber, useful for cascading state into later chambers' visibility conditions (§4.4).

Scripted actions are how a confederated-chatbot conformity study can be made literally identical across participants: the rules say “disable the human's input for 30 s after the first confederate's message” or “highlight the confederate's response in green for 5 s”, and the chat then unfolds with the same scaffolding in every session.

5.5.2 LLM-chosen Carrier actions

The alternative — and the more powerful in open-ended designs — is to let the language model itself decide which Carrier interventions to fire. This is the mechanism by which an LLM-driven mediator can act contextually: if the model judges that one participant has been quiet for too long, it can choose to issue a prompt_participant; if it judges that the conversation has drifted off-topic, it can choose to send a styled broadcast.

The rule does not pre-specify the action's parameters. Instead, the trigger fires an LLM call (with the bot's system prompt and chat context), and the model returns a structured response of the form

{
  "content":   "<broadcast text, or null>",
  "rationale": "<one-sentence justification, logged>",
  "actions":   [ { "type": "prompt_participant",
                   "target": "slot:2",
                   "message": "What do you think?" },
                 { "type": "disable_chat",
                   "target": "slot:1",
                   "release_conditions": { ... } } ]
}

The model's selection of actions is constrained by the bot's configured action vocabulary (researchers can choose to expose only a subset of action types to the model) and by the bot's role: a communicator's action vocabulary is small (no disable_chat); a mediator's is large. This mechanism is available to any LLM-driven mediator — both LLM chatbots and agents acting in a mediator role.

This is the most expressive — and also the least replicable — corner of Carrier intervention. The trade-off is real: an LLM-chosen action set gives you a facilitator that adapts, but the cost is that two sessions of the same condition may diverge in their facilitation. The right choice depends on what the experiment is testing.

5.5.3 Segment-submission actions

The interactive segments introduced in §2.2 — selection, ranking, and input — collect an answer from every participant in the chamber. A non-human participant configured as a communicator can be set up to submit alongside the humans, the way a confederate in a behavioural lab study would. The submission is attached to the bot's participant identity, surfaces in the segment's results, and appears in the exported data with the same shape as a human's answer.

What the bot submits depends on the segment type. For a selection, it is one or more option indices (or, in slider mode, a numeric value within the slider range). For a ranking, it is a permutation of the item indices. For an input, it is a string — or a number, for the numeric input subtype. In every case the submission shape mirrors the human's, so cross-participant aggregates and downstream variable expressions (§4) read bot and human submissions uniformly.

Where the value itself comes from is configured per trigger. Carrier supports four data modes:

• Static — the researcher hardcodes the value. The bot submits exactly that, every session. Useful when the value is the manipulation.
• Random — the value is drawn from a configured pool, optionally weighted. For selection and ranking the pool is the segment's own options; for input it is a researcher-provided list of candidate strings, since “random text” without an anchor is not meaningful.
• Referenced — the value is derived from what humans have already submitted in the same segment. Strategies include match the first human's answer, match the majority option, oppose the majority, and pick a different option at random. For selection and ranking all four strategies translate naturally; for input, only verbatim copy of a target human's text is well-defined.
• LLM-generated — the bot calls the language model with the segment's prompt, the chamber's chat context, and a JSON-shaped schema instruction. The model returns a structured submission (an index, a permutation, or a string). This is the most flexible mode and the one most often appropriate for input.

Three submission-metadata flags refine how the bot's answer is treated by the rest of the chamber. countTowardTotal decides whether the bot's submission contributes to the “everyone has answered” check that releases the chamber forward — set to false if the bot is a passive confederate that shouldn't gate progression. showInResults decides whether the submission appears in any aggregated results display participants see at the segment's end. tagAsBot decides whether the submission is visually marked as bot-origin in the UI; the default is false, so the bot is indistinguishable from the humans, which is usually what a confederacy design requires.

input deserves a brief separate note. Free-text submissions raise sharper measurement-validity questions than categorical or ordinal ones: a bot's prose is harder to compare across sessions than a chosen option, and small differences in wording can have outsized effects on the humans who read it. The recommended pattern when using input with LLM-generated mode is a tightly scoped system prompt, the raw model output logged in the export for audit, and tagAsBot: true whenever participants will read the submission and the design should be transparent about its bot origin.

A worked example: a confederacy study runs a selection segment (“Which option do you find more compelling?”) followed by an input segment (“In one sentence, why?”). Two configured bots use static mode in the selection segment, picking option A in every session; in the input segment they switch to LLM-generated mode under a system prompt instructed to elaborate on option A in plain, peer-like language. The participant sees four answers in each segment — two human, two bot — and across sessions the design holds: the bots' selections are reproducible to the index, and the bots' free-text answers vary in surface form while cohering around the same content.

5.5.4 Agent built-in tools (Claude Agent API)

The fourth mechanism is internal to the agent itself, and only applies to participants of the agent type (§ note on non-human participants). A Claude Agent has access to a vocabulary of built-in tools provided by the Anthropic Agent API — tools for reading files in a configured document area, executing small commands, and browsing the web. Before producing the message it will eventually send to the chat, the agent's underlying model can autonomously decide to invoke one or more of these tools, examine the results, and iterate.

A typical pattern, from the chamber's point of view:

1. A trigger fires that asks the agent to respond.
2. The agent reads (silently) the section of the configured study brief that is relevant to the conversation so far.
3. The agent runs (silently) a short check against a dataset to confirm a number it is about to cite.
4. The agent produces a single chat message that quotes the relevant passage and reports the number.

Steps 2 and 3 are internal to the agent. Participants in the chat see only step 4 — a single grounded reply. The agent's internal trace (which tools it called, with what arguments, and what results it got back) is preserved in the exported data for the researcher to audit, but it is not shown to other participants.

The two design decisions a researcher makes for an agent are therefore:

• Tool scope. Which of Claude's built-in tools to enable, and — for the file-reading tool — what document area to expose. The narrower the scope, the more focused the agent's contributions; the wider the scope, the more open-ended.
• Step budget / latency. Agents take longer per response than LLM chatbots, because they loop. Configure a maximum step count (or wall-clock budget) so the agent does not hold up the chamber. The platform shows a “thinking” indicator while the agent is in its loop.

Two notes on relating 4.5.4 to 4.5.2:

• An agent acting as mediator can fire LLM-chosen Carrier actions (4.5.2) and use its built-in tools (4.5.4) in the same turn. The former affects the chat; the latter informs the model.
• The two channels are logged separately in the exported data. The Carrier action log records intervention actions; the agent trace records tool invocations.

5.5.5 Choosing among the four mechanisms

§5 · Triggers

5.6 Composing triggers

5.6.1 Reading a script: the three views

A chamber's agents are authored together in the Script Builder, which shows the same set of triggers three ways. They are not decoration: each answers a question the others cannot.

5.6.2 The Timeline view, and what it catches

The Timeline lays the chamber's segments out as bands, one lane per agent, and places a mark for every segment a trigger is armed in. Each band carries its own ruler starting at 0:00, because that is the clock the runtime keeps (§5.3.3). A trigger with no segment scope therefore appears once in every compatible band — which is what actually happens to it.

• A filled pin is a scheduled time, straight from the trigger's delay.
• A hatched bar is a reactive trigger — keyword, regex, after-agent-message. It has no position in time, only a window in which it is armed.
• A bar with an open right edge is an idle timeout: earliest that time, then any time after, or never.
• A dashed violet bar is a chain-only trigger, which has no condition of its own and runs when something else chains to it.
• A grey pin in an amber hatch is armed past the end of its segment. It will not run.

Beneath the bands, a panel reports what the schedule actually does. Every row is computed from the configuration alone — no run required — and each one is a failure that is otherwise invisible until a pilot:

• a time trigger armed past the end of the segment it runs in;
• a trigger with no segment scope that silently re-arms in every segment;
• a chain-only trigger that nothing on any agent chains to;
• a trigger scoped to a segment whose type cannot run it — a response trigger parked on an instruction segment, say.

The same checks run on Deploy, so a script that cannot work is reported before participants meet it rather than after.

5.6.3 Composition modifiers

Real bots rarely consist of a single trigger. The composition surface lets you make the rules interact:

• Priority. Each trigger has a numeric priority. When multiple triggers' conditions are satisfied by the same event, Carrier evaluates them in descending priority order and fires the highest-priority match. Use priority to handle exceptions: an attention-check trigger with high priority can override a greeting trigger that would otherwise also fire.
• Cooldown. A trigger can specify a minimum interval that must elapse between successive firings. Used to prevent a bot from spamming when a condition stays true for a while.
• Max fires. A trigger can cap how many times it ever fires per chamber (e.g. an introduction trigger that only fires once).
• Probability. A trigger can fire with a configured probability less than 1.0 when its condition is satisfied, producing stochastic interventions.
• Chain target. A trigger can specify another trigger's ID to fire after it completes. This is how multi-step behaviours are built: trigger A says something, then chains to trigger B which fires a follow-up question after a delay, which chains to trigger C which records the response. The chained trigger's condition can be chain-only, which means it can only ever fire by being chained — useful for keeping cascading sequences out of the normal trigger queue. A chain target is resolved across every agent in the chamber, not just the one that owns the chaining trigger, so one agent can hand off to another — which is why the Script Builder shows all of a chamber's agents side by side, and draws the chains between them.

Together, these modifiers turn a flat list of triggers into a directed graph of contingent behaviour. Most experiments need only flat lists; the modifiers are there for designs that demand them.

5.6.4 Variable conditions in triggers (again)

The variable-filter modifier from §5.3.2 deserves a second mention here because of its compositional consequences. A single trigger list with variable filters

TRIGGER 1   if var.condition == "treatment", respond with X
TRIGGER 2   if var.condition == "control",   respond with Y

is functionally equivalent to two bots, one per condition, with one trigger each. Whether to write the contrast as “one bot with two filtered triggers” or “two bots, one per condition” is a design decision: the former keeps the experiment shorter and easier to read; the latter is sometimes clearer when the two conditions differ in many small ways.

§5 · Triggers

5.7 Builder walkthroughs

This concludes Part I. The four systems — chamberlines/chambers/segments, roles, variables, and triggers — together define everything a Carrier experiment can express. Part II turns to running an experiment built with them.

§6 · Running

6.1 The experiment lifecycle

Every experiment moves through a small lifecycle. Its status field — visible at the top of the builder and on the dashboard — takes one of five values:

The transition from Draft to Active is the activation step. The builder will refuse to activate an experiment that has obvious gaps — no chamberlines, an unfilled bot template, an invalid variable reference — but it will not catch every error. Pilot every experiment against yourself (and ideally a colleague) before opening it to real participants.

§6 · Running

6.2 The dashboard at a glance

The dashboard is the experimenter's command surface during a live experiment. It has four panels, of which the first three are tightly coupled.

Active sessions. A list of every participant currently in a run, with their current phase (initialisation / identity setup / global pre-survey / chamber line execution / global post-survey / completed), the chamberline they were assigned to, and the index of the chamber they are currently in. Clicking a participant opens a per-participant detail view.

Matching queue. A list of every participant currently waiting to be matched into a chamber. Each entry shows the chamber the participant is waiting for, how long they have been waiting, and what slot constraints (§4.3) need to be satisfied for them to be admitted. A queue that grows steadily during an experiment is the symptom of a constraint that is too tight.

Alerts. A rolling list of events that warrant attention: disconnects, long waits, drop-outs, and idle participants. The dashboard surfaces these in priority order; experimenters typically watch this panel rather than the others.

Chatrooms. A list of every active chatroom (matched chamber). Each entry can be opened to show the live transcript, the broadcast log, the action log, and the processor-interaction log. This is the place to watch a chamber unfold in real time.

The dashboard auto-refreshes; no manual refresh is required.

§6 · Running

6.3 Live monitoring and intervention

Three kinds of intervention are available from the dashboard during a live session.

Pause a participant's run. Halts the run at its current phase. The participant sees a paused indicator; segments and chamber timers do not advance. Resume with a single click. Use when a participant has hit a problem you want to debug before they continue.

End a participant's run. Terminates the run with a configurable completion message. The participant is shown the message and the global post-survey is skipped (unless explicitly forced). Used for participants who cannot continue — disconnections that will not heal, attention-check failures, withdrawal requests.

Host-advance a segment. Forces a segment whose transition mode is host (see §2.5) to advance for the chamber. Used during pilots to step a chamber through its timeline without waiting for timers or for participant clicks.

A fourth, lighter intervention — broadcast a message into a chatroom — is available from the chatroom detail view. The message appears in the chat as an experimenter announcement. Use sparingly: every dashboard broadcast is recorded in the chat transcript, so it becomes part of the dataset.

§6 · Running

6.4 Exporting data

Data export is the final step of an experiment. It is available from the experiment detail page and the dashboard.

Two parameters control what comes out:

The four export types correspond to four levels of granularity:

• Participants. One row per participant per chamberline assignment, with their identity, demographics, status, and variable values.
• Chatrooms. One row per chatroom (matched chamber), with the chamber's participants, settings, and timestamps.
• Responses. All survey responses across all surveys (global pre, global post, chamber pre, chamber post, embedded segment surveys), keyed by participant and survey ID.
• All. Every preceding type, plus the full chat transcripts and the broadcast / action / processor-interaction logs.

For a quantitative analysis pipeline, Responses and Participants in CSV are usually the right starting point; for a qualitative pass over conversation, All in JSON gives you the structure to operate on.

Exports are produced on demand; there is no waiting queue. For very large experiments, the export endpoint accepts a participant filter, so you can export a single chamberline or a single date range without downloading the entire experiment.

For a category-by-category description of what each export actually contains, see §6.5.

§6 · Running

6.5 What's in your data

An export is not a single thing. It is a layered snapshot of a run viewed from several angles — the survey angle, the conversation angle, the timing angle, and so on. Most analysis questions touch two or three of these layers at once. This section walks through what Carrier captures for every run, what it does not capture, and which export type each kind of data lands in.

The map below shows, at a glance, which export type carries which category. All is a superset; researchers who plan to do anything beyond the simplest summary should default to it.

The eight sub-sections that follow describe each category in turn, including the cases in which a category is empty by design.

6.5.1 Survey responses

For most studies, this is the primary data. Carrier captures survey responses in four places:

• The global pre-survey, completed before any chamber, once per run.
• The global post-survey, completed after the final chamber, once per run.
• Chamber pre- and post-surveys, completed at the boundaries of each chamber.
• Embedded segment surveys — the survey segment type — completed within a chamber as part of its segment timeline.

Two shapes come out together. The raw Survey.js JSON preserves nested question structures (matrices, panels, conditional branching) and is appropriate when the response shape itself matters. The flattened response rows give one row per question per participant, with questionId, questionText, response, responseType, and a stage indicator pointing at the survey instance the answer belongs to.

For most quantitative pipelines, Responses in CSV is the right starting point. For qualitative analyses or for questions where the survey was deliberately non-trivial, All in JSON preserves the structure you need to operate on.

6.5.2 Chat transcripts

Every message exchanged in every chatroom is preserved verbatim. Each message carries a sender (human participant, LLM chatbot, scripted chatbot, agent, mediator bot, or system), an ISO timestamp, and a message type that distinguishes ordinary text from system notifications, joins and leaves, mediator broadcasts, bot and AI responses, and processor suggestions.

System messages are interleaved with the conversation rather than stored on the side, which means a researcher reading the transcript chronologically sees joins, disconnects, broadcasts, and attention-check events in situ. Chatrooms and All exports include the full chat history; Participants does not.

6.5.3 Timing and pacing

Several layers of timestamps come out together.

• Run-level. When the run started, when each phase transitioned, when the run completed or was terminated, and the reason for termination.
• Chamber-level. When matching happened, when the chatroom began, when each segment within the chamber started, when the chamber ended, and the actual elapsed duration.
• Per-message. Every chat message carries an ISO timestamp.
• Connection-level. Heartbeats, reconnection counts, and the participant's total time in the experiment.

These together let researchers reconstruct any per-participant duration of interest — time-to-first-message, time between segments, time spent re-reading instructions — without custom instrumentation.

6.5.4 AI and processor interactions

When chambers use the processor role, every assist event is logged with its full text. Review interactions carry the draft text that was submitted, the feedback that came back, and whether the communicator accepted, rejected, or edited the suggestion. Generate interactions carry the request and the generated response. Real-time assist suggestions carry their content and outcome.

For chambers that use an LLM chatbot, mediator, or agent, the model's reply is stored in the chat history alongside human messages, with sender metadata identifying the role and, where set, the provider. For agents on the Claude Agent path — where memory is provider-managed — the provider's session handle is preserved on the chatroom so that Carrier-side and provider-side timelines can be aligned after the fact.

6.5.5 Behavioural events

When client-side instrumentation is active for a segment, Carrier captures a stream of low-level events: tab visibility changes, focus changes, pointer activity, clicks, and a small set of custom events raised by specific segment types. Per-segment summaries are produced automatically — most commonly tab-away count and total tab-away time — and the raw event stream is preserved for replay or fine-grained sequence analysis.

This data is opt-in by segment. Researchers who want it should confirm that the relevant segments have behavioural-events instrumentation enabled in the builder before piloting.

6.5.6 Attention checks and face monitoring

The attention-check segment captures a result record per attempt: the mode (face-based or survey-based), whether it passed, the retry count, and any mode-specific details. The record appears in two places — a structured array attached to the run, and a corresponding system message interleaved into the chat transcript at the moment of the check.

Face monitoring, when enabled on a chat segment, emits its own event stream: warning shown, face returned, grace expired, paused, resumed, terminated. It is stored the same way: a structured array on the run plus interleaved system messages in the transcript.

Both categories are present only when the experiment was configured to produce them. Their absence in an export is not a missing value; it means the experiment did not ask for them.

6.5.7 Assignment and reproducibility

For anyone who needs to reconstruct, after the fact, why a given participant saw what they saw, the export carries:

• The chamberline each participant was assigned to, and the reason (random, counterbalance, survey-based, or fixed).
• A frozen snapshot of the participant's run plan — the chambers in their assigned order, each with its role and slot assignment for that participant.
• The experiment's version at the moment the run was created, so that a later configuration change does not corrupt the interpretation of earlier runs.
• A condition seed where randomisation was involved.

Combined with the admin-side activity log (see §7), this is sufficient to reproduce a participant's path through the experiment exactly.

6.5.8 What's conditional

Several categories appear only when the experiment is configured to produce them. Worth flagging up front, so that an absent column is not mistaken for a bug:

• Behavioural events require client-side instrumentation enabled on the relevant segments.
• Attention-check results require an attention-check segment in the chamberline.
• Face-monitoring events require face monitoring enabled on a chat segment.
• Processor interaction logs require at least one chamber to use a processor role.
• Non-human sender metadata (role, provider) is populated when the message originates from a chatbot, mediator, or agent; for human messages those fields are empty by design.
• Variable values appear only for variables the experiment defined; there are no system-provided demographic variables.

If a researcher expects one of these and finds it missing, the place to check is the experiment configuration, not the export.

§6 · Running

6.6 Pilot first, ramp second

A short note that does not fit anywhere else in this guide but matters in practice. Every Carrier experiment benefits enormously from a small pilot — three to five participants, ideally including the researcher themselves — before being opened to a larger sample. Pilots are the only reliable way to catch the kinds of issues that the builder cannot validate: a slot constraint that is unsatisfiable in practice, a chamber timing that is too short to read the instructions, an LLM mediator whose system prompt produces unexpected behaviour on real conversations, a survey question that is ambiguous to actual participants.

Pilot with the experiment status set to active and the dashboard open. Watch the matching queue, watch the chat transcripts, and watch the action log. Most experiments end up requiring at least one round of revision after the first pilot. This is normal; budget time for it.

§7 · Administration

7.1 Accounts and collaboration

Every researcher account in Carrier has a role: either researcher or admin. Researchers can create, edit, run, and export their own experiments; admins additionally manage the user list and the activity log.

An experiment has one owner and any number of collaborators:

• The owner can edit everything, transfer ownership, add and remove collaborators, and delete the experiment.
• A collaborator can edit the experiment's configuration and view its data, but cannot transfer ownership, add other collaborators, or delete the experiment.

This separation is the simplest model that supports the common pattern of one PI owning each study and several lab members helping to configure and run it.

§7 · Administration

7.2 The admin portal

The admin portal is available only to users with the admin role. It exposes three sub-areas.

User management. Create, update, enable, and disable user accounts. Disabling an account preserves all of the user's experiments and data but prevents them from logging in. This is the right action when a lab member leaves; deletion is rarely necessary.

Registration approval. When self-registration is enabled, new sign-ups arrive in a pending state. The admin reviews each request — typically by checking the requester's institutional email and the project they intend to use Carrier for — and approves or rejects.

Activity logs. A chronological log of meaningful actions across the platform — logins, experiment creations, role changes, exports. Useful both for accountability and for understanding usage patterns when scaling the platform across multiple labs.

Appendices

Appendix A · Glossary

Appendices

Appendix B · Type × Role compatibility matrix

Reproduced from §3.1 for quick reference. The only forbidden combination is scripted chatbot as processor.

Appendices

Appendix C · Segment types — quick index

Every segment type, with the section that documents it. The descriptions live in §2.2; this index is deliberately a pointer rather than a second copy of them.

Appendices

Appendix D · Trigger types — quick index

Appendix

Appendix E · Walkthrough — building a social feed

A tour of the Feed Builder, from the seeded demo experiment to a feed saved in the database. It covers the same ground as §2.16 in the order you would actually meet it.

1 · General — the workspace

Three columns, and they are the whole job. The outline on the left is the feed as a timeline of arrivals, with the cast of accounts beneath it — two panes scrolling independently, so a feed of a hundred posts never buries the cast. Agents get a row each with their binding inline; crowd accounts, which a CSV import derives one-per-handle and which do nothing at run time, wrap as chips. The editor in the middle follows whatever is selected. The preview on the right is the participant’s own view, rendered in the participant stylesheet rather than an impression of it.

2 · Layout is not presentation-only

Switch the layout above the preview and three things move together: the preview re-renders, the affordance chips change (votes lights up only on Reddit), and the Forum fields group opens. On the other two layouts that group is dimmed and states its own condition, because those layouts render none of it and cannot collect a vote at all. This is the setting most worth understanding before you run anyone — see the validity note in §2.16.

3 · Edit a post, and see it as a participant would

Pick a post in the timeline and the centre column follows; the preview updates when you leave the field. Timing is authored as a direction and a unit — before entry, at entry, after entry — rather than as raw milliseconds. Seed comments are edited as the thread they already are, with Reply inserting a child; on Instagram and Facebook that button disappears on a comment that is itself a reply, because those layouts render one level only.

4 · Save refuses an invalid feed, and says why

A new seed comment starts empty, and an empty comment is not a valid feed. The same goes for a post with no caption, and for an agent account bound to nothing. Worth knowing before you fight it: an unbound agent account is an error, not a warning — the feed will not save and the experiment will not deploy until you bind it or turn it back into a crowd account.

5 · Find things in a long feed

The filter matches post id, caption and author, and never renumbers anything, so it is safe to filter and then act on what is shown. Past eight distinct arrival times the timeline groups into Before entry · On entry · After entry and moves each post’s own offset onto its row.

6 · Agents — who replies, and how

An agent account’s persona prompt, provider and model, temperature, context window, when it speaks and its reply delay — all without leaving the Feed Builder. These fields belong to the chamber agent, not to this feed: it is the same agent card that sits on the builder canvas, so the edits apply immediately rather than waiting for the feed’s Save.

7 · An account with nothing behind it

Select an unbound account and there is no form to fill — there is nothing to configure until something replies as it. The tab offers the bind instead, and the readiness chip in the header counts it among the things to fix. An agent already bound to another account is offered disabled, with the reason: one chamber agent answers as one account.

8 · Closing the readiness loop

The other way out: in General, select the account and set its kind to Crowd. It keeps authoring posts and seed comments and stops claiming it will answer; the agent-only fields (binding, scope, reply delay) go with it, and the readiness count falls.

9 · Feed — every post at once

A sortable table of the whole feed, with row selection and bulk Retime, Reassign author and Delete. Above it, arrival on a real axis in three bands, because a backlog post at −2h and a post at +45s cannot share one linear scale without collapsing the segment itself to a sliver. The amber band is posts scheduled after the segment ends — authored, exported, and never seen.

10 · Deploy

Save closes the Feed Builder and writes to the builder’s model; the experiment reaches the database through the builder’s own Update, which re-validates every segment — blocking on errors, pausing on warnings. The warning here is the honest one: reddit-only fields authored while the layout is Instagram. They stay in the data and come back if you switch, but they are not rendering now.