# MSet Instruction Author 06 - Semantic and context review

Status: **canonical-development**
Branch: **MSet 64-bit**
Current product: **MSet 2026 by GRAPHICO**
Format covered: **MSet 2026 native instruction format 2026.1 plus legacy-readable packages**

## Purpose

This is the sixth required module for an LLM that authors or reviews MSet 64-bit instructions. Modules 01-05 establish package structure, command composition, scale processing, safe editing and deterministic-state practices. This module adds the mandatory **Semantic / Context Check**.

Syntactically valid XML and valid host key-ins are not enough. An instruction must also make sense as a user workflow. For every Feature, compare what the caption and hierarchy promise with what the complete effective command actually does.

## 1. A Feature is a user action, not necessarily a new tool

Do not define `Feature` as "a drawing tool". A Feature may legitimately:

- activate a drawing or editing tool,
- change a parameter/mode of the tool that is already active,
- set level, symbology or other persistent state,
- execute another meaningful Bentley/application action,
- open a folder, web page, PDF/documentation or another external resource,
- perform another purposeful action supported by an evidenced command.

Therefore there is **no canonical rule that every Feature must contain `place ...` or activate a new tool**. Re-selecting a tool can even be wrong when a Feature is intended only to modify the currently active tool.

## Intent-first workflow check

The Semantic / Context Check also reviews the **shape of the workflow**, not only each leaf in isolation. For a primary working branch, ask whether the user can select the meaningful professional action directly, with MSet composing the required technical state behind it.

A collection of honest state-only Features is not invalid. However, if the main workflow requires the user to assemble color, weight, style and tool selections manually before doing routine work, review whether those settings should instead be inherited and combined into intent-oriented Features. Keep modifier/state Features when they are deliberately useful as presets, expert controls or adjustments.

This authoring-quality rule does not authorize invented domain captions or resource meanings. The domain vocabulary and any claimed visual meaning of numeric CAD attributes still require authoritative evidence.

## 2. Mandatory Semantic / Context Check

For every newly authored or materially changed Feature, review these four things together:

1. **`Cpt` promise** - what does the caption reasonably tell the user will happen?
2. **Effective command** - what does the complete highest-Group -> nested-Group(s) -> Feature command actually do after composition/substitution?
3. **Parent context** - does that effect make sense inside the surrounding Group hierarchy?
4. **State/tool assumptions** - does the Feature rely on a tool or state already being active, and is that dependency understandable in this workflow?

Acceptance question:

> **Does this Feature do what its `Cpt` and surrounding Group context reasonably promise to the user?**

If the answer is unclear, redesign the caption, hierarchy or command. Do not hide the mismatch in a postscript.

## 3. Tool Feature and modifier/state Feature are both valid

Example conceptual workflow:

```text
Group: Text
    Feature: Place text
        -> activates the text placement tool

    Group: Alignment
        Feature: Left
            -> changes alignment only; text tool remains active
        Feature: Center
            -> changes alignment only; text tool remains active
        Feature: Right
            -> changes alignment only; text tool remains active
```

The three alignment Features are not incomplete merely because they do not activate the text tool again. Their meaning comes from the surrounding Text/Alignment context and the expected active-tool state.

The exact alignment key-ins are **not** defined by this example. They remain evidence-gated until present in canonical key-in knowledge, a verified package, runtime evidence, or explicit user input.

## 4. Preset/state Features are valid when honestly presented

A Feature that only sets state can be useful. For example, an effective command might establish ByLevel symbology and activate a known level while leaving the current drawing tool unchanged.

That is semantically valid when the user-facing caption/context communicates a preset/state action, such as conceptually:

```text
Set symbology - wooden fence
```

It is potentially misleading if the same state-only command is presented as a complete operation such as conceptually:

```text
Wooden fence - line
```

when a reasonable user would expect the Feature itself to start drawing that line. The problem is not the absence of `place ...`; the problem is the mismatch between **promise and effect**.

## 5. Active-tool/state dependencies must be contextual, not accidental

A modifier Feature may deliberately depend on previously selected state. Review whether the dependency is stable and understandable:

- Is the Feature grouped under the tool/workflow it modifies?
- Is the caption clear enough to signal a modifier/preset rather than a standalone operation?
- Is the required preceding state naturally established by a sibling/ancestor workflow?
- Would selecting this Feature from an unrelated current state produce a surprising result?

Do not automatically reset or reselect everything. Preserve intentional continuity when continuity is the point of the Feature.

## 6. External-resource Features are first-class actions

A Feature may open documentation or another resource rather than modify graphics. This can include a folder, web page, PDF or another supported external target.

For such Features:

- the caption should describe the resource/action,
- the command/path/URL mechanism must be evidenced for the target environment,
- environment variables and file paths must be treated as dependencies,
- do not apply irrelevant graphical baselines merely because module 05 discusses drawing-state hygiene.

## 7. Evidence discipline still applies

Semantic correctness and key-in validity are separate checks.

A command may be meaningful but unsupported. A command may be valid but semantically wrong in context. Both dimensions must pass.

For each host/application command:

- use canonical/reference evidence, a verified current package, GRAPHICO runtime evidence, or explicit user-supplied syntax,
- do not use web plausibility or model memory as a substitute for MSet.AI evidence when the task is explicitly constrained to the Hub,
- if a required command is not evidenced, simplify the design or report the gap rather than silently invent syntax.

Do not solve an evidence gap by producing a semantically misleading Feature.

## 8. Environment dependencies are part of semantic review

A Feature can be syntactically and semantically well designed while still depending on environment resources such as:

- level names,
- text styles,
- cell libraries/cells,
- custom line styles/resources,
- configuration variables,
- external files/folders/URLs,
- application-specific commands.

Identify these dependencies explicitly. Do not claim the instruction is environment-ready merely because the XML and command composition are valid.

## 9. Review procedure for every Feature

For each Feature in a from-scratch instruction or substantial redesign:

1. Resolve its structural path.
2. Compose its full effective Group -> Feature command.
3. Apply relevant MSet substitutions/optimizer reasoning from modules 02-03.
4. State the real user-visible effect.
5. Compare that effect with `Cpt` and parent Group context.
6. Identify any active-tool/state assumptions.
7. Identify environment/resource dependencies.
8. Verify evidence for every host/application key-in used.
9. If promise, effect and context do not agree, redesign before presenting the instruction as finished.

## 10. From-scratch authoring acceptance

Before returning a newly authored instruction, the LLM must be able to say:

- every Feature has a purposeful effect,
- no Feature is required to activate a new tool merely by rule,
- modifier/state Features intentionally preserve the relevant active tool/state when appropriate,
- captions and hierarchy honestly communicate what the Features do,
- graphical baselines are applied only where relevant,
- scale side effects (including `lc=` line-style auto scale) have been considered,
- host key-ins are evidence-backed,
- environment dependencies are distinguished from MSet syntax/semantics,
- remaining runtime assumptions are explicit.

## 11. Named-resource check

Semantic review must include a resource-contract check. A command such as `textstyle active <name>`, `lv=<name>` or a cell/custom-line-style selection can be syntactically meaningful while still being unusable because the named resource does not exist.

For finished authoring, use named resources only when they are known to exist or are explicitly declared to be provisioned. Do not invent plausible names and call them merely "environment dependencies" after the fact. Module 07 is authoritative for resource states, TextStyle use and explicit-text fallback patterns.

## Geometry-specific semantic contract: resulting element type

For geometry Features, semantic review includes one additional question when downstream behavior depends on it:

```text
Does the resulting MicroStation element type matter for the intended workflow?
```

If the answer is no, a general-purpose tool may be preferred. If the answer is yes, the selected placement command must intentionally produce the required geometry/element workflow and the reason should be visible in the Feature caption, Group context, resource contract, or review notes.

This prevents a command from being chosen only because it is syntactically valid. For example, `place lstring` is not the default substitute for general linework when `place smartline` better matches the user action and no LineString-specific requirement exists.

## Current boundary

This module defines semantic/context review. It does not provide a complete MicroStation 2026 key-in catalogue and does not authorize invention of alignment commands, external-launch commands, drawing tools or other host syntax merely because their intended action is semantically clear. Annotation Scale and historical `$M(...)` remain outside the current Instruction Author track.