No-Match Results Due to SI Problems

One of the more confusing grammar problems is a recognition that should have matched but returns no result — or, through the Media Server, comes back as a no-match. The cause is often not the recognition at all. The ASR matched the utterance correctly, but the ECMAScript that builds the semantic interpretation (SI) result threw an error, so no SI could be produced and the result was discarded. This article explains why that happens, how to recognize it in your logs, and the one-line grammar change that almost always fixes it.

What the Error Means

When an ASR decode runs — whether driven through Capacity Private Cloud's gRPC speech APIs (SpeechPort) 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.

If the ECMAScript inside those <tag> elements is not written correctly, the processor can raise an error. When it does, the recognition itself may have been perfectly valid, but the SI cannot be produced — so no full result is returned, or, in the case of the Media Server, a no-match is returned in its place.

This is what makes the problem hard to spot: ECMAScript errors are not grammar syntax errors, and they surface at a different stage. A grammar can be syntactically perfect — its rules parse cleanly and the ASR uses it without complaint — yet the ECMAScript in its tags only runs when the parse tree is interpreted at runtime. These SI errors are therefore difficult to catch before runtime, which is exactly why they can be so tricky to diagnose.

Reproducing the Problem

The grammar below is syntactically valid and recognizes "one" or "two" without issue. The defect is in the semantics: MyChoice is assigned a value in the root <tag> without first being declared with a var statement.

When this grammar is used, the interpretation fails and an error like the following appears in your ASR client log (client_asr.txt):

The message is cryptic, but the root cause is precise: because MyChoice was never declared with var, the interpreter treats it as read-only, and any later attempt to use or assign it fails. The recognition succeeded; the SI could not be built on top of it.

Resolving the Problem

Declare MyChoice with a var statement the first time it is introduced, in the root <tag>. That is the only change required — everything else in the grammar stays the same.

With MyChoice properly declared, the ECMAScript processor can assign to it, the SI is produced, and the grammar returns the expected output.

Declare every variable with var the first time you introduce it in an SI script. An undeclared variable becomes read-only, and any subsequent assignment to it raises an ECMAScript error that silently discards an otherwise valid recognition. Declaring variables up front keeps the interpretation step from failing after a successful decode.

Testing and Diagnosing Grammars

The Grammar Tester in the Deployment Portal is the fastest way to catch SI errors like this one before they reach production. It parses a grammar 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 fix in seconds. Because ECMAScript errors only surface when the parse tree is interpreted, running a representative input through the Grammar Tester is the most reliable way to expose them. See the Portal Help Guide for a walkthrough.

Note that the platform periodically updates the ECMAScript processor used internally by the ASR, so some behaviors may evolve over time as the ECMAScript specification advances. When in doubt, validate against the current engine using the Grammar Tester.

Related Articles

• Unexpected [object clsGeneral] in SI
• Intro to Semantic Interpretation
• Getting the Return Value
• SI Script by Example