Adopt reviewed semantic-continuity wording

README.md

@@ -8,11 +8,11 @@
 
 A central principle is:
 
-> **Execution must not sever semantics.**
+> **Semantics must remain explicit through execution.**
 
-Executable behavior should remain machine-traceable to the semantic knowledge that gives it meaning.
+Executable behavior should remain machine-traceable to the semantic knowledge that gives it meaning. The earlier wording **“Execution must not sever semantics”** remains useful as explanatory shorthand for the failure mode this positive requirement prevents.
 
-For a deeper explanation of this invariant, including failure modes, provenance versus semantic continuity, and the Pizza example, see [Semantic Continuity — Why Execution Must Not Sever Semantics](docs/semantic-continuity.md).
+For a deeper explanation of this invariant, including failure modes, provenance versus semantic continuity, and the Pizza example, see [Semantic Continuity — Keeping Semantics Explicit Through Execution](docs/semantic-continuity.md).
 
 ```text
 Semantic Knowledge
@@ -337,7 +337,7 @@ Capability / Execution / Result / Verification
 Service / Agent / Deployment
 ```
 
-> **Execution must not sever semantics — and execution architecture should not become the accidental owner of domain semantics.**
+> **Semantics must remain explicit through execution — and execution architecture should not become the accidental owner of domain semantics.**
 
 See [Pizza executable reference](examples/pizza/README.md).
 
@@ -382,7 +382,7 @@ The project intentionally does **not** begin as a general software framework, LL
 ## Documentation
 
 - [Semantic models](model/README.md)
-- [Semantic Continuity — Why Execution Must Not Sever Semantics](docs/semantic-continuity.md)
+- [Semantic Continuity — Keeping Semantics Explicit Through Execution](docs/semantic-continuity.md)
 - [Related Work and ESKA Positioning](docs/related-work.md)
 - [Knowledge Service Generalization](docs/knowledge-service-generalization.md)
 - [Knowledge Agent Generalization](docs/knowledge-agent-generalization.md)

docs/related-work.md

@@ -10,9 +10,9 @@ This document positions ESKA against those traditions. Its purpose is not to cla
 
 The defining invariant is therefore:
 
-> **Execution must not sever semantics.**
+> **Semantics must remain explicit through execution.**
 
-ESKA requires concrete execution and results to remain machine-traceable to the formal semantic knowledge and Semantic Capability that give the execution its meaning.
+ESKA requires concrete execution and results to remain machine-traceable to the formal semantic knowledge and Semantic Capability that give the execution its meaning. The earlier wording **“Execution must not sever semantics”** remains useful as explanatory shorthand for the failure mode this invariant prevents.
 
 ## Prior-art qualification
 
@@ -313,4 +313,4 @@ The shorter architectural thesis is:
 
 This related-work review is intentionally architectural rather than exhaustive. It prioritizes works that materially overlap with at least two of ESKA's concerns: formal semantics, executable knowledge, capability contracts, runtime execution, provenance/verification, and agent/service accessibility.
 
-Future related-work additions should strengthen or falsify the contribution statement. They should not cause ESKA core vocabulary to grow merely because a neighboring architecture has more concepts.
+Future related-work additions should strengthen or falsify the contribution statement. They should not cause ESKA core vocabulary to grow merely because a neighboring architecture has more concepts.

docs/semantic-continuity.md

@@ -1,11 +1,13 @@
-# Semantic Continuity — Why Execution Must Not Sever Semantics
+# Semantic Continuity — Keeping Semantics Explicit Through Execution
 
 A central ESKA principle is:
 
-> **Execution must not sever semantics.**
+> **Semantics must remain explicit through execution.**
 
 This means that when formally represented knowledge becomes operational, the running system should not lose the machine-interpretable meaning that explains what the execution is doing, under which conditions it is valid, and how its result relates back to the governing semantic source.
 
+The earlier formulation **“Execution must not sever semantics”** remains useful as explanatory shorthand for the failure mode this positive requirement prevents, but it is no longer the primary normative wording.
+
 ESKA is therefore not only concerned with making knowledge executable. It is concerned with keeping knowledge **semantic while it becomes executable**.
 
 ## The problem
@@ -43,7 +45,7 @@ The software can execute, but the runtime system may no longer be able to determ
 
 The execution still works technically, but its semantics have become external knowledge held by developers, documentation, prompts, or convention.
 
-That is what ESKA calls **severing semantics**.
+That is what the earlier shorthand **“execution severs semantics”** describes.
 
 ## Semantic continuity instead
 
@@ -111,6 +113,8 @@ Execution
 
 The implementation may therefore be optimized, compiled, distributed, wrapped behind an API, or deployed independently without becoming semantically opaque.
 
+An implementation projection is not mandatory. A source-owned semantic artifact may participate in execution directly; when a projection is introduced, its relevant meaning and lineage must remain explicit and traceable to the authoritative source.
+
 ## Provenance is necessary, but not sufficient
 
 Provenance can tell us:
@@ -285,7 +289,7 @@ Can the architecture determine, in machine-readable form:
 
 If the chain stops at "this function/service produced this output," semantic continuity is weak or broken.
 
-If the chain reaches the formal semantic source and preserves the meaning of the operation along the way, execution has not severed semantics.
+If the chain reaches the formal semantic source and preserves the meaning of the operation along the way, semantics remain explicit through execution.
 
 ## Concise formulation
 
@@ -303,4 +307,6 @@ Executable
 
 That is the architectural commitment expressed by:
 
-> **Execution must not sever semantics.**
+> **Semantics must remain explicit through execution.**
+
+The earlier **“Execution must not sever semantics”** remains a concise way to name the failure this principle is intended to prevent.

examples/pizza/README.md

@@ -420,10 +420,12 @@ GerhardBalz/executable-semantic-knowledge-architecture
 
 Two principles are executable rather than merely documented:
 
-> **Execution must not sever semantics.**
+> **Semantics must remain explicit through execution.**
 
 > **Execution architecture should not become the accidental owner of domain semantics.**
 
+The earlier wording **“Execution must not sever semantics”** remains useful as shorthand for the first principle's failure mode.
+
 ## Source and license
 
 See [LICENSE-NOTICE.md](LICENSE-NOTICE.md) for the cross-repository provenance and licensing boundary.