The merge-resolver comments in tools/merge-resolver/src/lib.rs and src/decision.rs describe decision records as VeriSimDB “hexads”. That count-specific term can be mistaken for a six-element contract. The number-agnostic term proposed for an implementation's selected modalities is modality profile; Octad should be used only when referring to the current upstream's named eight-modality API/model.
The legacy src/verisimdb.rs client uses custom collection/snapshot routes, so this is a terminology/documentation clarification—not a request to rename its wire routes or to port it to the current API.
Please review and update relevant comments/docs to:
- use “modality profile” for a selected/configured group of modalities;
- reserve “Octad” for the exact current upstream contract, and remove unqualified “hexad” where it does not mean exactly six elements;
- clearly label the persistence client as legacy/custom until its contract is checked.
No transport or record format should change without an agreed contract. Related upstream terminology proposal: hyperpolymath/verisimdb#299.
The merge-resolver comments in
tools/merge-resolver/src/lib.rsandsrc/decision.rsdescribe decision records as VeriSimDB “hexads”. That count-specific term can be mistaken for a six-element contract. The number-agnostic term proposed for an implementation's selected modalities is modality profile; Octad should be used only when referring to the current upstream's named eight-modality API/model.The legacy
src/verisimdb.rsclient uses custom collection/snapshot routes, so this is a terminology/documentation clarification—not a request to rename its wire routes or to port it to the current API.Please review and update relevant comments/docs to:
No transport or record format should change without an agreed contract. Related upstream terminology proposal: hyperpolymath/verisimdb#299.