Cequation
Cequation is a proprietary expression engine utilized across the Contacter ecosystem to seamlessly access, evaluate, and modify datasets within both CTT files and persistent databases. A Cequation statement is architected into two logical scopes: the Evaluation (Calculus) side, which queries data and computes results, and the Assignment (Attribution) side, which dictates which variable state or schema property to mutate. It also features out-of-the-box iterative loops designed to process multi-element array structures efficiently.
A Cequation can be executed in two behavioral states:
- Single-sided: Executes the evaluation logic only (read-only compute path).
- Multi-sided: Evaluates the runtime logic and assigns the resulting value to a variable, a specific CTT metadata element, or an external database index.
Calculus
:::warning Calculus (Evaluation Scope)
The evaluation logic is declared on the right side of the statement. This scope accesses variable attributes from the CTT structure and computes multi-element operations. Every expression is evaluated using Reverse Polish Notation (RPN) / Postfix Notation, meaning you declare your operands first, followed by the operator. All operators and operands must be isolated from one another using a single empty space separator (" ").
:::
Example:
"{$call.trust 10 +}"
Explanation: This statement targets the global trust score of the call, retrieves its value, and increments it by 10 via postfix addition.
1. Operands
The Cequation runtime supports four distinct categories of operands: CTT Fields, Database Fields, Local Variables, and Constants.
A. CTT Fields
$– Root identifier token mapping directly to the CTT file schema (excluding database pointers)..– Dot-notation operator used to traverse down nested object properties.
Example:
"{$call.trust}" # Traverses the parent 'call' dictionary to target the 'trust' property.
Deep JSON Traversals
You can query nested JSON structures by specifying absolute path strings or using safe fallbacks:
"{$call.trust}" # Accesses 'trust' nested inside 'call'.
"{$speaker.SPEAKER_0000.trust}" # Accesses 'trust' for a specific speaker ID string.
"{$dialog.0.text}" # Extracts the raw text string from the first dialogue array index.
"{$dialog.5::''.text}" # Extracts text from the 6th index; returns a fallback empty string '' if it does not exist.
Dynamic Index & Dictionary Targeting ([variable:default]+/-N)
Enables dynamic index mapping for runtime dictionary traversal and list mutations:
"{$speaker.[myspeaker].trust}" # Queries the speaker matching the runtime value of the 'myspeaker' variable.
"{$dialog.[mydialog:0]-1.trust}" # Selects the dialogue array block preceding 'mydialog' (defaults to index 0; lists only).
Property Sorting & Ranking (property:rank_index:default)
Arrays and structured dictionaries can be sorted sequentially based on an internal sub-property before extraction:
"{$speaker.duration:0:0.trust}" # Sorts speakers by duration, isolates the lowest value (0), and queries their trust. Returns a fallback 0 if the dataset is null.
"{$speaker.duration:-1.language.duration:-1.duration}" # Isolates the speaker with the highest duration (-1) and extracts the length of their most-spoken language.
Introspection Keywords ($keys and $key)
Provides runtime key introspection methods over dictionary blocks:
"{$speaker.$keys}" # Returns an array containing all active speaker ID keys.
"{$speaker.duration:-1.$key}" # Identifies the speaker with the highest duration and extracts their string key name.
Structured Group Aggregations over Object Fields (property:aggregation_method)
Executes mathematical or lexical calculations across all sub-elements for a target sub-property:
"{$dialogspk.text:join}" # Concatenates all transcript text entries associated with a single speaker channel.
"{$dialog.duration:avg}" # Computes the mathematical average duration across all dialogue entries.
Available Group Operations (Objects):
sum– Accumulates the total mathematical sum of all matching numeric properties.avg– Calculates the mathematical mean across all matching numeric properties.wavg– Computes a weighted average score mapped against segment durations (e.g., duration-weighted phrase trust).join– Linearly concatenates matching string payloads into a single text sequence.
Group Aggregations over Scalar Arrays (:aggregation_method:default)
Executes functional loops directly across raw scalar collections (such as primitive string lists):
"{$dialog.[my].tags::.:join:}" # Merges all string items inside the tags array. Returns '' if the array is null or empty.
Available Group Operations (Scalars):
sum/avg– Mathematical summation or mean calculations over scalar numeric lists.join– Delimiter-based merging over scalar string lists.
Payload Compaction (property_1, ..., property_N)
Generates an isolated JSON slice containing only the specified sub-properties from the target object.
B. Local Variables
Variables previously instantiated during an assignment step can be evaluated inside subsequent expressions. To reference a local variable, you must prefix its user-defined tracking identifier with a leading dot (.).
"{.variable 10 +}" # Retrieves the cached value of '.variable' and increments it by 10.
C. Database Fields
You can programmatically retrieve specific storage blocks by defining targeted table arrays, target columns, and custom conditional evaluation gates:
"{$db.table.field.[condition]}"
The lookup [condition] execution path can natively incorporate independent Cequation evaluation layers.
Example:
"{$db.agent.id.[code='{$main.agent}']}" # Queries the 'id' column from the 'agent' table where 'code' matches the compiled string token evaluated from '{$main.agent}'.
D. Constants
The evaluation architecture natively parses three core primitive constant datatypes:
int– Declared by passing raw, unquoted integer numeric digits.float– Declared by passing unquoted non-integer decimal numeric values.bool– Enforced by passing the explicit boolean keywordsTrueorFalse.
Examples:
"{$call.trust 10 +}" # Evaluates the integer value 10.
"{$call.duration 0.5 +}" # Evaluates the floating-point decimal value 0.5.
"{speaker.duration:-1.key SPEAKER_0000 =}" # Evaluates the equality mapping against the literal string token 'SPEAKER_0000'.
2. Operators
The Cequation engine supports a robust set of logical, mathematical, and lexical operators. Because the runtime operates on Reverse Polish Notation (RPN), these operators always evaluate the operands declared immediately preceding them in the execution stack.
A. Logical Operators
AND- Accepts two boolean operands and returns a boolean result.
- Accepts one boolean operand and one operand of any other data type: if the boolean evaluates to
True, it returns the value of the other operand; ifFalse, it returnsNone.
OR- Accepts two boolean operands and returns a boolean result.
NOT- Accepts a single boolean operand and returns its logical negation.
B. Comparison Operators
>/</>=/<=- Accept two numerical operands (integers or floats) to perform standard relational comparisons.
==/!=- Accept two numerical operands for value equality/inequality matching.
- Accept two string operands for exact literal string matching.
C. Mathematical & Structural Operators
+- Accepts two numerical operands to perform standard arithmetic addition.
- Accepts two string operands to perform direct text concatenation.
- Accepts one operand and one
Nonetoken; the engine bypasses the null state and returns the value of the active operand. - Accepts two dictionary operands and returns a single merged dictionary containing keys from both objects.
- Accepts two list arrays and returns a single extended list combining all elements.
-/*//- Accept two numerical operands to perform standard arithmetic subtraction, multiplication, or division.
ROUND.N- Accepts a single floating-point operand and returns the numeric value rounded precisely to
Ndecimal places.
- Accepts a single floating-point operand and returns the numeric value rounded precisely to
D. Text & Lexical Processing Operators
TEXT.IN.word1.word2...wordN- Accepts two string operands. It scans the target string payload and returns an integer representing the frequency count of the specified dot-separated keyword tokens discovered within the text.
TEXT.DIGIT- Accepts a single string operand. Yields
Trueif the string consists exclusively of numerical digits; otherwise, returnsFalse.
- Accepts a single string operand. Yields
TEXT.DIGIT.GET- Accepts a single string operand. Parses and extracts the native
intvalue if the string is numeric; returnsFalseif structural parsing fails.
- Accepts a single string operand. Parses and extracts the native
PREFIX.token_string- Accepts a single string operand. Prepends the specified
token_stringto the main operand (token_string + main_operand).
- Accepts a single string operand. Prepends the specified
POSTFIX.token_string- Accepts a single string operand. Appends the specified
token_stringto the end of the main operand (main_operand + token_string).
- Accepts a single string operand. Appends the specified
Assignment (Attribution Scope)
The Assignment scope defines both the destination where data is committed and the structural execution path used to write it.
Example:
$call.trust: ... # Targets the global trust score inside the CTT schema for value assignment.
1. Programmable Control Structures
The assignment layer natively supports code grouping blocks, loop blocks, and iterative datasets.
A. Logical Code Grouping
You can consolidate multiple execution steps into a single logical group to improve script readability. To instantiate a group block, prefix the identifier key with a leading underscore (_).
_my_custom_group:
- temporary_var: "{ Calculus 1 }"
- $call.trust: "{ .temporary_var ... }"
Note: Group components can natively accept, nest, and process complex dictionary structures and array lists.
B. Iterative Loops
You can execute loops to iterate across keys and indexes within an existing dictionary or list. To trigger an iteration loop, use the ? character as a syntax prefix.
"?speaker.[myspeaker]":
- "$speaker.[myspeaker].profile": "{$output.speaker.[myspeaker].profile}"
- "$speaker.[myspeaker].justification": "{$output.speaker.[myspeaker].justification::}"
Explanation: This directive iterates through all active dictionary keys inside the speaker repository, binding the current iterator to the myspeaker reference variable.
The engine can similarly execute loops over sequential lists:
?dialog.[mydialog]:
- $dialog.[mydialog].trust: 1
Note: The loop iteration architecture utilized within ainter_*.yaml configuration manifests follows a specialized extension separate from this standard framework convention.
2. Direct Value Allocation
When structuring an assignment, you can choose between two allocation methods: using the evaluation engine or passing a direct literal value.
- Evaluated Allocation: Invokes the expression Evaluation Engine. The payload must be a valid string block that the engine parses to pull data points from CTT memory logs or database layers.
- Direct Allocation: Bypasses expression parsing entirely and maps a static, constant primitive value straight to the target schema element.
Examples:
$dialog.-1.text: "And the Call Ended" # Appends a direct literal string to the target field.
$dialog.-1.duration: 2.3 # Assigns a direct float constant to the duration property.
$call.language: {} # Flushes the target dictionary property back to an empty object.
3. Dynamic Node Creation
Cequation allows you to dynamically append entirely new keys to dictionary objects or push new element payloads onto sequential lists.
Examples:
$call.supervisor: "supervisor1" # Instantiates the 'supervisor' key if it is missing from the parent structure.
$dialog.[]: {"uuid": "genuuid4", "speaker": "SPEAKER_0000"} # Appends a new block to the list array (the token 'genuuid4' triggers automatic UUID generation).
Deep Element Path Provisioning (^ and ^^)
Standard behavioral boundaries prevent you from setting deep nested paths inside a non-existent parent element (i.e., you cannot assign a leaf node until its branch exists). While direct allocation can declare nested structures in a single block, evaluation scopes cannot. To bypass this restriction and force the engine to dynamically provision parent containers at runtime, use the ^ (dictionary) and ^^ (list) path initialization prefixes:
$call.^supervisor.name: "John Nobody" # Forces the engine to provision 'supervisor' as an empty dictionary if missing.
$call.^^words: ["one", "two", "three"] # Forces the engine to provision 'words' as a structured array list if missing.
4. Target Destination Ingestion
Assignments can route data changes into three distinct runtime destination targets: Local Variables, CTT Schema Layers, and Database Target Schemas.
Target A: Local Variables
Caching computed metrics inside temporary local variables allows you to share intermediate values across downstream expressions. To declare a variable, pass a naked identifier key that does not start with a $ token (otherwise, the engine will attempt a CTT write operation).
long_silence_val: "$dialog.[my].start $dialog.[my]-1:0:num.end - round.1"
Explanation: The local tracker long_silence_val captures and stores the calculated evaluation result. Within downstream expressions, this variable can be recalled using a leading dot prefix (.long_silence_val).
Target B: CTT Schema Layers
Writing to a CTT node targets specific fields inside the local JSON interaction ledger. The syntax path mirrors the format used within the evaluation engine.
$call.trust: ... # Updates the global trust score property inside the call block.
$dialog.0.language.en.duration: ... # Updates the duration key nested under the 'en' object, inside the language map of the first dialogue array element.
You can inject variable references to build highly dynamic assignment paths:
$dialog.[mydialog].language.[mylanguage].duration: ... # Resolves the targeted dialogue index and language node using keys stored in memory or evaluated by a loop.
Constraint: All CTT database modifications must explicitly begin with a $ token prefix (excluding the $db namespace reservation). The baseline properties permitted for mutation depend on the execution tool and context wrapper.
Target C: Relational Storage Layers
Writing to a storage target triggers transactional mutations (INSERT or UPDATE statements) inside your database layer. The underlying database schema layout must be registered inside your placer_*.yaml configuration sheets.
# Targets the interaction table using an UPSERT configuration
"$db.interaction[*]:idinteraction":
"id": "{$uuid}"
"idcustomer": "{.idcustomer}"
"idagent": "{$db.agent.id.[code='{$main.agent}']}"
"startdate": "{$main.date}"
"enddate": "{$main.date}"
"duration": "{$origin.durationorig}"
"mainlanguage": "{$call.mainlanguage}"
"summary": "{$call.summary}"
"vsummary": "{$call.summary}"
"metadata": "{$call.(channel,volumeorig,gaincorr,volumecorr,nospeechprob,langprob,comratio,trust,wordnumber,language)}"
An ingestion statement to a database starts by declaring the target table schema (in this instance, interaction). Upon transaction completion, the resulting primary key generated by the database is cached inside the target variable appended to the command (:idinteraction).
The nested attributes map explicit column names to their required value assignments. These payloads accept complex evaluation strings that can aggregate data points from CTT records, reference memory variables, or perform sub-queries against other tables.
For instance, the idagent field runs a localized sub-query against the agent table, parsing an inner evaluation statement ({$main.agent}) to pull dynamic tokens from the active session ledger. The ingestion engine automatically manages format serialization across numeric, string, JSON, and vector types.
Transactional Write Operators
To prevent data corruption, updating records typically requires passing an explicit primary key index. While unconstrained conditional updates are supported, they are treated as unsafe since an invalid evaluation rule can corrupt entire data columns. The platform exposes five explicit operational modes to manage insertion and update boundaries securely:
[]– Standard INSERT: Executes a strict insertion block (automatically throws a transactional exception if the record index already exists).[+]– Safe INSERT: Commits the record only if the target index is missing (silently skips execution if the record exists).[*]– UPSERT (Insert or Update): Commits a new record if missing, or overwrites existing column attributes if a record matches.[=]– Standard UPDATE: Executes a strict update block against an existing row (fails automatically if the target index is missing).[unsafe:{condition}]– Unconstrained Query Path: Bypasses standard tansaction safeguards to execute loose updates based on custom conditions. Use with extreme caution.
Combining Iterative Loops with Database Ingestion
You can embed transactional write blocks inside control loops to commit batch arrays efficiently:
"?dialog.[mydial]":
"myspeaker": "{$dialog.[mydial].speaker}"
"$db.phrase[*]:idphrase":
"id": "{$dialog.[mydial].uuid}"
"idinteraction": "{.idinteraction}"
"starttime": "{$dialog.[mydial].start}"
"endtime": "{$dialog.[mydial].end}"
"speaker": "{.myspeaker}"
"profile": "{$speaker.[myspeaker].profile}"
"text": "{$dialog.[mydial].text}"
"vtext": "{$dialog.[mydial].text}"
"tags": "{$dialog.[mydial].tags::.:join:}"
"metadata": "{$dialog.[mydial].(duration,channel,volumeorig,gaincorr,volumecorr,mainlanguage,nospeechprob,langprob,comratio,trust,wordnumber,language)}"
Target D: Heuristic Metadata Tags
You can leverage Cequation to evaluate conditions and programmatically apply metadata tags. These tags can be bound to the overall call schema, to specific speaker profiles, or to individual dialogue phrases within the transcript.
The engine processes two distinct categories of tags:
-
Boolean (Name-Only) Tags: These tags serve as single binary indicators. For example,
$UNCERTAIN_AUDIOacts as a boolean flag showing that a transcript segment carries low confidence scores. To declare a boolean tag, map the tag identifier directly to the assignment side:$UNCERTAIN_AUDIO: "$dialog.[my].logprob -0.7 < $dialog.[my].nospeechprob 0.4 < and"Rule: The evaluation block must resolve to a boolean state. If
True, the tag is instantiated inside the schema node; ifFalse, it is omitted. -
Key-Value Tags: These tags append dynamic metric string values to the tag name identifier. The underlying evaluation expression must return a dual-token stack: a boolean validating whether the tag condition is met, and a value payload to be concatenated with the tag key.
long_silence_val: "$dialog.[my].start $dialog.[my]-1:0:num.end - round.1"$LONG_SILENCE: ".long_silence_val postfix.s .long_silence_val 4 >"Explanation: This expression calculates the silent interval preceding the current phrase, appends a
"s"unit token, and evaluates if the total duration exceeds 4 seconds. The tag is initialized only if the conditional statement yields a true state. The resulting entry is serialized inside the metadata ledger as a key-value pair (e.g.,LONG_SILENCE=4.1s).
Target E: Dynamic AI Prompt Injection
Within ainter_*.yaml configuration manifests, you use assignments to construct and shape context boundaries for SYSTEM and USER prompts. You can concatenate raw text layouts, bind targeted evaluation variables, and execute iterative data loops.
By default, prompt text inputs are treated as static literal blocks. The expression engine isolates and parses only the data tokens explicitly wrapped inside { ... } curly braces. Any text declared outside these brackets passes through the compiler unprocessed.
Example:
"Call Center call {$uuid} with {$origin.durationorig} sec. and with the following Tags: [{$call.tags::''.:join:''}]"
Resulting Compilation Output:
Call Center call 04becc58-e892-4e6b-ac7f-49cb6c4b9578 with 1032.228 sec. and with the following Tags: [mainspeaker=SPEAKER_0002 mainlanguage=en]
Target F: Transcription Pipeline Control (Redo)
Redo assignments map evaluation logic to dictate whether specific transcript phrase blocks must be pushed back into the speech-to-text pipeline for re-processing. This allows you to bypass general multi-language drifting issues. You can enforce a global language parameter to lock down the system, or write custom rule heuristics to target and re-transcribe low-confidence audio windows.
For instance, if a specific call participant speaks a dominant language for the vast majority of a call session, but isolated segments register high lexical ambiguity under a different language model prediction, you can force the speaker's primary language over those low-confidence windows to refine accuracy.
"dialog-langprob-is-small": "$dialog.[my].langprob 0.91 <"
"dialog-language!=speaker-max-language": "$dialog.[my].language $speaker.[my].language.duration:-1.$key !="
"speaker-max-language>80": "$speaker.[my].language.duration:-1.duration $speaker.[my].duration / 100 * 80 >"
"condition": ".dialog-langprob-is-small .dialog-language!=speaker-max-language .speaker-max-language>80 and and $speaker.[my].language.duration:-1.$key and"
Explanation: In this automated orchestration block, the evaluation pipeline resolves the final state of the local condition variable. If it returns a boolean True value, the system schedules a targeted re-transcription block using the speaker's primary language.
The condition variable can also return an explicit language string token directly. If a language code is resolved, that specific language is forced during the re-transcription process. If the statement evaluates to False or "", the re-transcription loop is bypassed.
Tools and Context Execution Matrix
Cequation behaviors dynamically adapt across the evaluation (Calculus) and assignment (Attribution) phases depending on the specific operational tool and context runtime.
1. Transcriber
The Transcriber architecture leverages the Cequation engine to govern two primary automation layers: Low-Confidence Re-transcription (Redo) and Contextual Tagging.
A. Transcription Pipeline Control (Redo)
During a Redo cycle, the entire right-side expression is handled directly by the evaluation core. While you can optionally wrap the entire statement inside { ... } tokens, you cannot nest individual bracketed evaluation variables within a mixed text string. The pipeline natively supports the instantiation and evaluation of local auxiliary variables.
The expression is evaluated dynamically once per dialogue phrase. Every iteration exposes the following root memory structures:
$call– Root object tracking overall call-session metadata.$speaker– Key-value directory tracking speaker performance indexes.$dialog– Chronological list array containing all dialogue phrase blocks.$dialogspk– A dynamically computed, ordered array filtering phrases specific to the current active speaker channel (Note: This is an unmapped helper array and is not stored natively in the static CTT file).
The execution loop exposes the following contextual iterator pointers:
mydialog– Points to the active phrase index within the$dialogarray (referenced via$dialog.[mydialog]).mydialogspk– Points to the active phrase index within the filtered$dialogspkhelper array (referenced via$dialogspk.[mydialogspk]).myspeaker– Points to the active speaker identifier within the$speakermap (referenced via$speaker.[myspeaker]).my– A polymorphic system tracking pointer that automatically inherits the index value ofmydialog,mydialogspk, ormyspeakerdepending on the schema structure declared in the preceding command token. For simplified clean syntax, it is highly recommended to pass$speaker.[my]or$dialog.[my].
B. Contextual Tagging (tag.yaml)
Tagging execution rules match the behavior of the Redo engine regarding expression parsing constraints and support for local variables. However, the compiler segments execution into three isolated structural scopes:
Scope 1: TAG_CALL (Evaluated once per call session)
- Available Structures:
$call,$speaker,$dialog,$dialogspk. - Contextual Variables: None.
Scope 2: TAG_SPEAKER (Evaluated iteratively once per active speaker)
- Available Structures:
$call,$speaker,$dialog,$dialogspk. - Contextual Variables:
myspeaker,my.
Scope 3: TAG_DIALOG (Evaluated iteratively once per dialogue phrase)
- Available Structures:
$call,$speaker,$dialog,$dialogspk. - Contextual Variables:
mydialog,mydialogspk,myspeaker,my.
2. Contacter
The Contacter CLI evaluates expressions to execute file inspections and state modifications across two explicit workflow profiles:
Profile A: Metadata Tagging
Mirrors the exact execution scopes, data architectures, and variable constraints detailed inside the main Transcriber module.
Profile B: CTT File Mutations (Assignments)
Enables developers to modify values within the target CTT ledger utilizing both expression evaluations and direct literal value allocations. The evaluation engine exposes three structural scopes: $call, $speaker, and $dialog.
You can append structural control loops to replicate assignment pipelines across every indexed key in a target dictionary object or list array. While loops are most commonly mapped to speaker and dialog layers, the interpreter natively evaluates loops across any valid nested object model:
# Iterates through all active speaker identifiers
?speaker.[myspeaker]:
- ...
# Iterates sequentially through all transcript dialogue lines
?dialog.[mydialog]:
- ...
# Deep path iteration: loops through all spoken language nodes for the first speaker array index
?speaker.0.language.[mylanguage]:
- ...
3. Ainter
The Ainter engine utilizes Cequations to manage context windows for prompt generation and to ingest responses parsed from AI endpoints.
Component A: Dynamic Prompt Assembly
Ainter leverages evaluation logic to construct context-rich parameters for SYSTEM and USER prompts. The assignment block accepts loop directives targeting speaker and dialogue data frames, and local variables can be instantiated freely. The accessible data maps adapt dynamically depending on the active loop boundary:
- Global Boundary (No Active Iteration Loop)
- Available Data Structures:
$call,$speaker,$dialog. - Contextual Variables: None.
- Available Data Structures:
- Speaker-Level Ingestion Loop (Triggers one execution block per speaker)
- Available Data Structures:
$call,$speaker,$dialog,$dialogspk. - Contextual Variables:
myspeaker,my.
- Available Data Structures:
- Dialogue-Level Ingestion Loop (Triggers one execution block per transcript phrase)
- Available Data Structures:
$call,$speaker,$dialog,$dialogspk. - Contextual Variables:
mydialog,mydialogspk,myspeaker,my.
- Available Data Structures:
Nesting Rules: You can embed an inner dialogue loop inside a parent speaker-level loop. When this nested architecture is initialized, the internal dialogue loop automatically acts as a filter, rendering phrases generated exclusively by that specific active speaker channel.
Component B: AI Response Payload Ingestion
When processing model responses, the engine grants concurrent read-access to both the local CTT file layers and the structured JSON object returned by the LLM gateway.
- Available Data Structures:
$call,$speaker,$dialog,$output(where the$outputpointer maps to the root JSON string parsed from the AI endpoint).
Variable scoping is restricted to the specific tracking pointers initialized within your control loops, enabling safe mutations across target fields:
# Loops through speakers to patch attributes from the JSON response
?speaker.[myspeaker]:
- ...
# Loops through dialogue segments to append AI metrics
?dialog.[mydialog]:
- ...
# Loops directly through a custom 'issue' array returned inside the LLM JSON payload
?output.issue.[myissue]:
- ...
4. Placer
The Placer database loader restricts operations exclusively to database target schemas (supporting INSERT, UPDATE, and UPSERT statements). Local auxiliary variables are natively supported to organize query structures.
The ingestion engine exposes three structural scopes to map datasets to database table columns:
- Available Data Structures:
$call,$speaker,$dialog.
Data mapping variables are resolved dynamically based on the explicit loop pointers declared inside your ingestion blocks:
# Iterates sequentially through dialogue indices to feed the relational phrase table
"dialog":
"?dialog.[mydial]":