diff --git a/.github/workflows/priority-c-refinement.yml b/.github/workflows/priority-c-refinement.yml
deleted file mode 100644
index 4b95958..0000000
--- a/.github/workflows/priority-c-refinement.yml
+++ /dev/null
@@ -1,368 +0,0 @@
-name: Priority C refinement
-
-on:
-  push:
-    paths:
-      - '.github/workflows/priority-c-refinement.yml'
-
-permissions:
-  contents: write
-
-jobs:
-  refine:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          token: ${{ secrets.GITHUB_TOKEN }}
-
-      - name: Apply focused Priority C refinements
-        shell: python
-        run: |
-          from pathlib import Path
-
-          refinements = {
-              "docs/40_boundary_state_runtime_definition.md": r'''
-
----
-
-## Priority C-10 Refinement
-
-The following distinctions refine the runtime reading without changing the Boundary State definition.
-
-### Boundary readability and target-relation readability
-
-A Boundary State requires a Boundary relation that is sufficiently identifiable for the classification to remain traceable.
-
-```text
-Boundary relation readability
-≠ target relation readability
-```
-
-For `Void` as a Boundary State:
-
-```text
-the relevant Boundary is identifiable,
-but the target relation cannot currently be read or connected sufficiently relative to that Boundary
-```
-
-When the Boundary distinction itself is not sufficiently readable, GyroOS should retain:
-
-```text
-unclassified Boundary evidence
-or
-unreadable distinction evidence
-```
-
-It must not automatically assign `VOID` as a Boundary State.
-
-### Confidence naming
-
-The recommended field name in `BoundaryStateRecord` is:
-
-```python
-boundary_state_confidence: float | None
-```
-
-This value is distinct from:
-
-```text
-boundary_readability
-Stability
-response_confidence
-```
-
-### Candidate-set status
-
-The full candidate set remains:
-
-```text
-NORMAL | NON | UN | ABSENCE | BLANK | UNKNOWN | VOID
-```
-
-A bounded PoC may implement only `NORMAL | UNKNOWN | VOID`, but that subset must not be treated as the closed GyroOS enum.
-''',
-              "docs/41_boundary_aware_slice_done.md": r'''
-
----
-
-## Priority C-10 Refinement
-
-The recommended naming for directly embedded objects and external references is:
-
-```text
-*_evidence
-= directly retained evidence objects
-
-*_records
-= identified classification records with lineage
-
-*_refs
-= references to externally retained records
-```
-
-A refined embedded form is:
-
-```python
-class SliceDone:
-    boundary_evidence: list[BoundaryEvidence]
-    boundary_state_records: list[BoundaryStateRecord]
-    void_evidence: list[VoidEvidence]
-
-    boundary_refs: list[str]
-    boundary_state_refs: list[str]
-    void_refs: list[str]
-```
-
-Implementations may use embedded objects, references, or both, but the naming must reveal which form is being used.
-
-`BoundaryStateRecord` is the preferred name for an identified provisional classification with lineage. `BoundaryStateEvidence` should be reserved for unregistered evidence that has not yet become such a record.
-
-The following values must remain separate:
-
-```text
-boundary_readability
-boundary_state_confidence
-Stability
-response_confidence
-```
-
-Also:
-
-```text
-Boundary not sufficiently readable
-≠ automatic VOID Boundary State
-```
-
-In that case, `SliceDone` may retain unclassified or unreadable Boundary evidence without forcing a Boundary State classification.
-''',
-              "docs/44_void_position_and_boundary_relation.md": r'''
-
----
-
-## Priority C-10 Refinement
-
-Void as a Boundary State must be read with two different readability questions kept separate:
-
-```text
-Boundary relation readability
-≠ target relation readability
-```
-
-The refined relation is:
-
-```text
-Void as Boundary State
-= the relevant Boundary is identifiable,
-  but the target relation cannot currently be read or connected sufficiently relative to that Boundary
-```
-
-Therefore:
-
-```text
-Boundary distinction itself is unreadable
-≠ automatic Void as Boundary State
-```
-
-When the distinction itself is not sufficiently readable, retain one of the following without forcing classification:
-
-```text
-unclassified Boundary evidence
-unreadable distinction evidence
-VoidEvidence not yet attached to a Boundary State
-```
-
-This preserves the separation among:
-
-```text
-Void as Boundary State
-VoidEvidence
-Void reference
-Operator Response
-```
-
-Void remains non-acting and does not independently select `DEFER`, `RESLICE`, `JUMP`, or `STOP`.
-''',
-              "docs/45_boundary_memory_and_trajectory_preservation.md": r'''
-
----
-
-## Priority C-10 Refinement
-
-Boundary-related storage should use the following naming discipline:
-
-```text
-BoundaryEvidence
-BoundaryStateRecord
-VoidEvidence
-```
-
-References to separately stored objects should use:
-
-```text
-boundary_refs
-boundary_state_refs
-void_refs
-```
-
-The memory layer must preserve the difference between:
-
-```text
-an unreadable Boundary distinction
-and
-a readable Boundary with a target relation classified as VOID
-```
-
-These must not share one undifferentiated `void` record.
-
-Recommended trajectory evidence keeps separate values for:
-
-```text
-boundary_readability
-boundary_state_confidence
-Stability
-response_confidence
-```
-
-Compression or resolution decay may summarize these values, but it must not merge them into one confidence score.
-
-A later readable Boundary or reclassification may supersede a record for the current scope, but the earlier unreadable distinction evidence, Boundary State record, and Operator Response evidence remain traceable through lineage.
-''',
-              "docs/46_boundary_aware_api_mapping.md": r'''
-
----
-
-## Priority C-10 Refinement
-
-The API naming rule is:
-
-```text
-*_evidence
-= directly embedded evidence objects
-
-*_records
-= identified classification records with lineage
-
-*_refs
-= identifiers of separately stored objects
-```
-
-A response may therefore expose either embedded values:
-
-```json
-{
-  "boundary_evidence": [],
-  "boundary_state_records": [],
-  "void_evidence": []
-}
-```
-
-or external references:
-
-```json
-{
-  "boundary_refs": [],
-  "boundary_state_refs": [],
-  "void_refs": []
-}
-```
-
-or both when explicitly documented.
-
-The following API values must remain separate:
-
-```text
-boundary_readability
-boundary_state_confidence
-stability
-response_confidence
-```
-
-An unreadable Boundary distinction should be represented as unclassified or unreadable Boundary evidence. It must not be converted automatically into:
-
-```text
-boundary_state = VOID
-operator_response = DEFER
-HTTP error
-```
-
-`VOID` is valid only when the relevant Boundary is identifiable and the target relation is insufficiently readable or connectable relative to it.
-''',
-              "docs/47_boundary_aware_poc_impact.md": r'''
-
----
-
-## Priority C-10 Refinement
-
-The first Boundary-aware PoC may retain the bounded subset:
-
-```text
-NORMAL | UNKNOWN | VOID
-```
-
-This is an implementation subset only. It must not be declared as the closed GyroOS Boundary State enum; the broader candidate set remains available to the runtime design.
-
-Use the preferred minimal object names:
-
-```text
-BoundaryEvidence
-BoundaryStateRecord
-VoidEvidence
-```
-
-The PoC output should display separately:
-
-```text
-boundary_readability
-boundary_state_type
-boundary_state_confidence
-stability
-operator_response
-response_confidence when implemented
-```
-
-The `VOID` scenario must establish:
-
-```text
-the relevant Boundary is identifiable
-and
-the target relation is not sufficiently readable or connectable relative to it
-```
-
-If the Boundary distinction itself is unreadable, the PoC should emit unclassified Boundary evidence rather than automatically assigning `VOID`.
-
-The deterministic decision rules remain PoC policy only. No rule may collapse Boundary State, Stability, and Operator Response into one value.
-''',
-          }
-
-          marker = "## Priority C-10 Refinement"
-          changed = []
-          for filename, appendix in refinements.items():
-              path = Path(filename)
-              text = path.read_text(encoding="utf-8")
-              if marker not in text:
-                  path.write_text(text.rstrip() + appendix.rstrip() + "\n", encoding="utf-8")
-                  changed.append(filename)
-
-          workflow = Path('.github/workflows/priority-c-refinement.yml')
-          if workflow.exists():
-              workflow.unlink()
-              changed.append(str(workflow))
-
-          print("Changed:")
-          for item in changed:
-              print(f"- {item}")
-
-      - name: Commit refinements
-        run: |
-          git config user.name "github-actions[bot]"
-          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
-          git add docs/40_boundary_state_runtime_definition.md \
-                  docs/41_boundary_aware_slice_done.md \
-                  docs/44_void_position_and_boundary_relation.md \
-                  docs/45_boundary_memory_and_trajectory_preservation.md \
-                  docs/46_boundary_aware_api_mapping.md \
-                  docs/47_boundary_aware_poc_impact.md \
-                  .github/workflows/priority-c-refinement.yml
-          git diff --cached --quiet || git commit -m "Refine Priority C Boundary-aware runtime documents"
-          git push
diff --git a/docs/40_boundary_state_runtime_definition.md b/docs/40_boundary_state_runtime_definition.md
index ee64408..f795b35 100644
--- a/docs/40_boundary_state_runtime_definition.md
+++ b/docs/40_boundary_state_runtime_definition.md
@@ -843,3 +843,61 @@ It does not modify the invariant Core.
 ```text
 Priority C-3: Boundary-aware SliceDone
 ```
+
+---
+
+## Priority C-10 Refinement
+
+The following distinctions refine the runtime reading without changing the Boundary State definition.
+
+### Boundary readability and target-relation readability
+
+A Boundary State requires a Boundary relation that is sufficiently identifiable for the classification to remain traceable.
+
+```text
+Boundary relation readability
+≠ target relation readability
+```
+
+For `Void` as a Boundary State:
+
+```text
+the relevant Boundary is identifiable,
+but the target relation cannot currently be read or connected sufficiently relative to that Boundary
+```
+
+When the Boundary distinction itself is not sufficiently readable, GyroOS should retain:
+
+```text
+unclassified Boundary evidence
+or
+unreadable distinction evidence
+```
+
+It must not automatically assign `VOID` as a Boundary State.
+
+### Confidence naming
+
+The recommended field name in `BoundaryStateRecord` is:
+
+```python
+boundary_state_confidence: float | None
+```
+
+This value is distinct from:
+
+```text
+boundary_readability
+Stability
+response_confidence
+```
+
+### Candidate-set status
+
+The full candidate set remains:
+
+```text
+NORMAL | NON | UN | ABSENCE | BLANK | UNKNOWN | VOID
+```
+
+A bounded PoC may implement only `NORMAL | UNKNOWN | VOID`, but that subset must not be treated as the closed GyroOS enum.
diff --git a/docs/41_boundary_aware_slice_done.md b/docs/41_boundary_aware_slice_done.md
index 2b1f92b..30e65ed 100644
--- a/docs/41_boundary_aware_slice_done.md
+++ b/docs/41_boundary_aware_slice_done.md
@@ -725,3 +725,55 @@ It does not modify the invariant Core.
 ```text
 Priority C-4: Boundary Readability and Stability
 ```
+
+---
+
+## Priority C-10 Refinement
+
+The recommended naming for directly embedded objects and external references is:
+
+```text
+*_evidence
+= directly retained evidence objects
+
+*_records
+= identified classification records with lineage
+
+*_refs
+= references to externally retained records
+```
+
+A refined embedded form is:
+
+```python
+class SliceDone:
+    boundary_evidence: list[BoundaryEvidence]
+    boundary_state_records: list[BoundaryStateRecord]
+    void_evidence: list[VoidEvidence]
+
+    boundary_refs: list[str]
+    boundary_state_refs: list[str]
+    void_refs: list[str]
+```
+
+Implementations may use embedded objects, references, or both, but the naming must reveal which form is being used.
+
+`BoundaryStateRecord` is the preferred name for an identified provisional classification with lineage. `BoundaryStateEvidence` should be reserved for unregistered evidence that has not yet become such a record.
+
+The following values must remain separate:
+
+```text
+boundary_readability
+boundary_state_confidence
+Stability
+response_confidence
+```
+
+Also:
+
+```text
+Boundary not sufficiently readable
+≠ automatic VOID Boundary State
+```
+
+In that case, `SliceDone` may retain unclassified or unreadable Boundary evidence without forcing a Boundary State classification.
diff --git a/docs/44_void_position_and_boundary_relation.md b/docs/44_void_position_and_boundary_relation.md
index 5931a0d..ea1f115 100644
--- a/docs/44_void_position_and_boundary_relation.md
+++ b/docs/44_void_position_and_boundary_relation.md
@@ -848,3 +848,48 @@ Stability
 ```text
 Priority C-7: Boundary Memory and Trajectory Preservation
 ```
+
+---
+
+## Priority C-10 Refinement
+
+Void as a Boundary State must be read with two different readability questions kept separate:
+
+```text
+Boundary relation readability
+≠ target relation readability
+```
+
+The refined relation is:
+
+```text
+Void as Boundary State
+= the relevant Boundary is identifiable,
+  but the target relation cannot currently be read or connected sufficiently relative to that Boundary
+```
+
+Therefore:
+
+```text
+Boundary distinction itself is unreadable
+≠ automatic Void as Boundary State
+```
+
+When the distinction itself is not sufficiently readable, retain one of the following without forcing classification:
+
+```text
+unclassified Boundary evidence
+unreadable distinction evidence
+VoidEvidence not yet attached to a Boundary State
+```
+
+This preserves the separation among:
+
+```text
+Void as Boundary State
+VoidEvidence
+Void reference
+Operator Response
+```
+
+Void remains non-acting and does not independently select `DEFER`, `RESLICE`, `JUMP`, or `STOP`.
diff --git a/docs/45_boundary_memory_and_trajectory_preservation.md b/docs/45_boundary_memory_and_trajectory_preservation.md
index a774bc7..283396d 100644
--- a/docs/45_boundary_memory_and_trajectory_preservation.md
+++ b/docs/45_boundary_memory_and_trajectory_preservation.md
@@ -710,3 +710,46 @@ Structure → Slice → Stability
 ```text
 Priority C-8: Boundary-aware API Mapping
 ```
+
+---
+
+## Priority C-10 Refinement
+
+Boundary-related storage should use the following naming discipline:
+
+```text
+BoundaryEvidence
+BoundaryStateRecord
+VoidEvidence
+```
+
+References to separately stored objects should use:
+
+```text
+boundary_refs
+boundary_state_refs
+void_refs
+```
+
+The memory layer must preserve the difference between:
+
+```text
+an unreadable Boundary distinction
+and
+a readable Boundary with a target relation classified as VOID
+```
+
+These must not share one undifferentiated `void` record.
+
+Recommended trajectory evidence keeps separate values for:
+
+```text
+boundary_readability
+boundary_state_confidence
+Stability
+response_confidence
+```
+
+Compression or resolution decay may summarize these values, but it must not merge them into one confidence score.
+
+A later readable Boundary or reclassification may supersede a record for the current scope, but the earlier unreadable distinction evidence, Boundary State record, and Operator Response evidence remain traceable through lineage.
diff --git a/docs/46_boundary_aware_api_mapping.md b/docs/46_boundary_aware_api_mapping.md
index a25182a..49cc382 100644
--- a/docs/46_boundary_aware_api_mapping.md
+++ b/docs/46_boundary_aware_api_mapping.md
@@ -868,3 +868,61 @@ Structure → Slice → Stability
 ```text
 Priority C-9: Boundary-aware PoC Impact
 ```
+
+---
+
+## Priority C-10 Refinement
+
+The API naming rule is:
+
+```text
+*_evidence
+= directly embedded evidence objects
+
+*_records
+= identified classification records with lineage
+
+*_refs
+= identifiers of separately stored objects
+```
+
+A response may therefore expose either embedded values:
+
+```json
+{
+  "boundary_evidence": [],
+  "boundary_state_records": [],
+  "void_evidence": []
+}
+```
+
+or external references:
+
+```json
+{
+  "boundary_refs": [],
+  "boundary_state_refs": [],
+  "void_refs": []
+}
+```
+
+or both when explicitly documented.
+
+The following API values must remain separate:
+
+```text
+boundary_readability
+boundary_state_confidence
+stability
+response_confidence
+```
+
+An unreadable Boundary distinction should be represented as unclassified or unreadable Boundary evidence. It must not be converted automatically into:
+
+```text
+boundary_state = VOID
+operator_response = DEFER
+HTTP error
+```
+
+`VOID` is valid only when the relevant Boundary is identifiable and the target relation is insufficiently readable or connectable relative to it.
diff --git a/docs/47_boundary_aware_poc_impact.md b/docs/47_boundary_aware_poc_impact.md
index a2f2744..82c8893 100644
--- a/docs/47_boundary_aware_poc_impact.md
+++ b/docs/47_boundary_aware_poc_impact.md
@@ -759,3 +759,46 @@ The next step is:
 ```text
 Priority C-10: Priority C Review and Refinement
 ```
+
+---
+
+## Priority C-10 Refinement
+
+The first Boundary-aware PoC may retain the bounded subset:
+
+```text
+NORMAL | UNKNOWN | VOID
+```
+
+This is an implementation subset only. It must not be declared as the closed GyroOS Boundary State enum; the broader candidate set remains available to the runtime design.
+
+Use the preferred minimal object names:
+
+```text
+BoundaryEvidence
+BoundaryStateRecord
+VoidEvidence
+```
+
+The PoC output should display separately:
+
+```text
+boundary_readability
+boundary_state_type
+boundary_state_confidence
+stability
+operator_response
+response_confidence when implemented
+```
+
+The `VOID` scenario must establish:
+
+```text
+the relevant Boundary is identifiable
+and
+the target relation is not sufficiently readable or connectable relative to it
+```
+
+If the Boundary distinction itself is unreadable, the PoC should emit unclassified Boundary evidence rather than automatically assigning `VOID`.
+
+The deterministic decision rules remain PoC policy only. No rule may collapse Boundary State, Stability, and Operator Response into one value.