Clarify final identity validation and overlay semantics

This commit is contained in:
2026-10-24 00:16:53 +00:00
parent 57edb8ec19
commit 25cf7ce05c
3 changed files with 18 additions and 7 deletions

View File

@@ -971,7 +971,9 @@ and typed decoding. Overlay bytes, nodes, and source records count toward the sa
aggregate limits as base inputs. Its canonical path must remain within the configured
root and must not duplicate a file already present in the base graph.
Overlay is intentionally distinct from strict composition:
Collection destinations follow the
[collection operation and presence rules](#strict-document-composition) above.
The following table describes ordinary overlay behavior elsewhere:
| Existing lower node | Incoming overlay node | Result |
| --- | --- | --- |
@@ -980,9 +982,10 @@ Overlay is intentionally distinct from strict composition:
| Mapping | Mapping | Recurse by mapping key |
| Any other pair of present nodes | Any other pair of present nodes | Replace the entire lower node |
Scalars, sequences, and null are atomic. Thus an overlay sequence replaces rather
than extends a base sequence, `[]` clears it, null is an explicit replacement, and
cross-kind replacement is allowed when the final application schema accepts it.
Under these ordinary rules, scalars, sequences, and null are atomic. An overlay
sequence replaces rather than extends a base sequence, `[]` clears it, null is an
explicit replacement, and cross-kind replacement is allowed when the final
application schema accepts it.
Replacing a subtree removes all displaced descendants from effective presence and
origin data; history retains the displaced definitions and identifies the parent
replacement. Surviving overlay paths have overlay origins, while recursively shared