One Grammar, Two Readers
The same Semantic Intent block can be read two ways. A deterministic parser turns it into tool configuration — that is ChirpIQX. A language model executes it as a runtime directive without being told to — that is cal_verify_case. Same grammar, two consumers. The second is the "emitted directive" of Paper 3, and seeing them side by side answers whether any of this is more than prompt engineering.
The Comment That Named It
Line 13 of verify-case.ts reads: “the MCP uses semantic intent to guide Claude’s intelligence.” It was a developer’s note, not a thesis — a one-line explanation for why the tool works the way it does.
It turned out to describe something worth a paper: a tool whose output is a directive a model executes. But the comment captures more than one idea. The other had been running quietly in a different tool for months — where the same kind of block is read not by a model, but by code.
The Grammar
Every Semantic Intent block follows the same shape: what it needs, what it will do, what it returns, what it costs.
I analyze free agents and recommend pickups and breakout candidates.
I need: position filter (optional array), ownership threshold (optional number),
max results (optional number)
I will: Yahoo API calls, statistical analysis, trend detection
I return: top pickups with scores, breakout candidates, position breakdown
I estimate: moderate complexity, 3000 tokensThis is not prose about a tool. It is a structured contract — parameters, capabilities, a cost estimate. The structure is the point, and it is what makes the block readable by two completely different kinds of reader.
Reader One: The Parser
In ChirpIQX — a fantasy-hockey MCP server, now public — that block is read by code. A small deterministic parser, SemanticIntentParser, walks the I need / I will / I return sections with regex rules and returns typed configuration.
const parsed = new SemanticIntentParser().parseIntent(intent)
// parameters: [{ name: 'position_filter', type: 'array', required: false }, ...]
// capabilities: ['yahoo_api', 'data_analysis']
// confidence: 1.0No model is involved. The block is the tool’s declared definition; the parser turns it into the tool’s MCP input schema, its capability tags, and a confidence score. One artifact, two readers: a human reads the description, a machine reads the spec — and there is a validateParser() test suite asserting it extracts the right thing.
This is declared Semantic Intent: written at definition time, parsed into configuration.
Reader Two: The Model
cal_verify_case, a fact linter in the CAL Workflow MCP server, takes the same grammar somewhere new. It does not declare a block. It generates one at runtime, calibrated to the specific case it is checking, and returns it as the tool’s output. The block ends like this:
NOW DO IT
Extract every checkable claim above. For each, use web_search to verify it
against current authoritative sources AND check whether its cited [N] source
actually supports it. Be skeptical. Then produce the contradicted-first report.The tool calls no model. It gathers the claims and the cited sources, wraps them in the directive, and hands it back. The conversational model reads the output, recognises an action plan, and — without being told to — runs the web searches and returns a contradicted-first report.
This is the emitted directive: Semantic Intent generated at runtime and executed by the receiver. It is the subject of Paper 3.
Side by Side
The two tools were built in different domains — one recommends waiver pickups, the other fact-checks case studies. They share a grammar and almost nothing else. That is the tell.
| ParsedChirpIQX SemanticIntentParser | Emittedcal_verify_case | |
|---|---|---|
| The SI block is | the tool's declared definition | a runtime-generated output |
| Read by | a deterministic regex parser | a language model |
| Produces | input schema + capabilities + confidence | an executed verification workflow |
| When | at tool-definition time | at runtime, calibrated to the artifact |
| Mode | declared → parsed to config | emitted → executed |
Same grammar. The consumer — a regex engine or a language model — is the parameter.
Is This Just Prompt Engineering?
The obvious objection to an “emitted directive” is that it is a fancy name for prose a model happens to follow. The side-by-side answers it.
The same grammar a language model executes in cal_verify_case is parsed by a regex engine in ChirpIQX — deterministically, under test. A structure a parser can turn into a schema and a model can run as a plan is not ad-hoc prose. It is a grammar. The grammar is the invariant; the consumer — a parser or a model — is the parameter.
The Catch: Artifact Fidelity
One honest limit. The emitted directive is only as truthful as the artifact it is built from.cal_verify_case is deterministic — the same case always produces the same directive — but determinism guarantees the directive reflects its input, not that the input is correct.
Run it on a stale copy of a case and it will faithfully generate a directive about the wrong version; the model will faithfully execute it; and the result will be confidently wrong. This actually happened the first time out: a flagged “contradiction” turned out to be a stale-copy artifact, not a real error. Intent preservation is a property of execution. Artifact fidelity is a property of input. Correctness needs both — which is the argument for verifying the published artifact, never a draft held in some client’s memory.
The Comment Was Right
The developer comment never distinguished the two readers. It did not need to. Both are the same idea: the Semantic Intent block is the interface, and what sits on the other side of it decides whether the block is parsed or executed. Paper 3 names the second case. ChirpIQX has been quietly running the first all along.