Unexpected [object clsGeneral] in SI

An interpretation result that reads [object clsGeneral] is one of the more common symptoms of an under-specified semantic interpretation (SI) script. It is not an engine fault — the recognition itself succeeded — but the ECMAScript that builds the SI result left a variable's type ambiguous, so the interpreter fell back to a generic object and rendered it as [object clsGeneral] instead of the string or number you intended.

This article explains why the generic-object result appears, how to reproduce it, and the one-line grammar change that resolves it.

What the Result Means

When an ASR decode runs — whether driven through Capacity Private Cloud's speech APIs or through the Media Server (MRCP) — the engine first produces a recognition result, then hands the matched grammar to the ECMAScript processor. That processor evaluates the grammar's semantic interpretation tags to build the final SI result your application consumes.

ECMAScript is loosely typed: a variable takes its type from the first value assigned to it. When a grammar uses a variable before giving it an unambiguous value — for example, applying += to a variable that was never initialized — the interpreter cannot infer whether you meant a string, a number, or something else. It initializes the variable as a generic Object, and when the SI processor serializes that object it emits the placeholder description [object clsGeneral].

The remedy is almost always the same: declare the variable with an explicit, unambiguous type the first time you use it. For the authoritative list of ECMAScript types, see §4.3.1 of the ECMAScript Language Specification.

Reproducing the Problem

The grammar below references a sub-rule and accumulates its return value into out using +=. Because out is never initialized, the first += operates on an undefined variable, and the interpreter creates it as a generic object:

Parsing an utterance against this grammar produces a single interpretation, prefixed with the generic-object placeholder:

• Number of Interpretations: 1
• Interpretation 1: [object clsGeneral]You said white

The recognition was correct — "white" was matched — but the leading [object clsGeneral] reveals that out started life as a generic object before the sub-rule's string was appended to it.

Resolving the Problem

Initialize out as an empty string before the first +=. This declares its type unambiguously, so the appended value extends a string rather than coercing a generic object:

With the variable explicitly typed, the same utterance now produces a clean result:

• Number of Interpretations: 1
• Interpretation 1: You said white

The Underlying Principle

The first time you use a variable in an SI script, assign it — or initialize it as — an unambiguous type. Initialize string accumulators as "", numeric accumulators as 0, and arrays as [] before applying operators such as += to them. Establishing the type up front prevents the interpreter from defaulting to a generic object and keeps your SI output predictable.

This pattern matters most in root rules that aggregate the results of one or more sub-rules. The root rule is where accumulator variables are typically introduced, so it is the right place to declare their type before any sub-rule value is folded in.

Testing and Diagnosing Grammars

The Grammar Tester in the Deployment Portal is the fastest way to diagnose SI issues like this one. It runs grammar parses against the platform's ASR engine, lets you submit input text and inspect the resulting interpretation without recording audio, and supports editing the grammar and re-testing immediately — so you can confirm a type fix in seconds. See the Portal Help Guide for a walkthrough of the Grammar Tester.

Related Articles

• Intro to Semantic Interpretation
• Getting the Return Value
• SI Script by Example
• No-Match Results Due to SI Problems