E.5.1:4 - Solution
Establish a Lexical Firewall around the Conceptual Core (conceptual constraint; not a build‑time linter):
-
Keep abstract definitions independent of incidental machinery. A Core definition SHALL NOT make an unrelated tool, file format, command or deployment arrangement necessary to identify or use its conceptual subject. Describe that subject directly; place the implementation in Tooling.
-
Retain necessary syntax for a governed concrete subject. When a rule governs a particular publication form, protocol or grammar, it MAY state the exact syntax needed to apply that subject’s conformance condition. Name the governed subject and edition or use boundary. The exception applies only where replacing the syntax with a conceptual alias would remove an operative condition. A heading marker in a heading grammar qualifies; an unrelated build command does not. Calling executable code a grammar example supplies no exception.
-
Keep executable teaching in its own source. A Core concept needing a runnable illustration cites the teaching or Tooling artifact by conceptual name. Runnable teaching programs, concrete execution paths and commands remain there. A subject-defining syntax fragment under item 2 is not a runnable illustration merely because it appears in a code span or block. Mathematical expressions follow E.5.2: explain their interpretation, operation and prerequisites, with semantic mapping when compared or translated.
-
Use aliases where they preserve the rule. An incidental technical term can be defined in a Tooling Glossary and cited by conceptual alias. Preserve necessary spelling under item 2 when the concrete subject’s condition would otherwise become untestable.
Non‑normative automation. Machine checks MAY exist in Tooling; they are advisory and MUST NOT be imported into the Core.