1 files changed, 21 insertions, 1 deletions
diff --git a/lib/kernel/rite.mli b/lib/kernel/rite.mli
index 6d12dd4..ffe9471 100644
--- a/lib/kernel/rite.mli
+++ b/lib/kernel/rite.mli
@@ -38,5 +38,25 @@ type ('s, 'r) t = {
           Low Sunday (searching onward from there only if that day is itself
           blocked). [occupant] is supplied rather than a raw layer/temporal
           pair so the rite never has to re-implement occurrence resolution
-          just to answer "what sits here". *)
+          just to answer "what sits here".
+
+          OBLIGATIONS (not enforced by the type, and {!Calendar}'s own
+          termination argument depends on both): the result must be
+          {b strictly later} than the [Date.t] argument (the date the
+          candidate was impeded on) -- {!Calendar}'s placement pass treats
+          [target = origin] or [target < origin] as a legitimate placement,
+          not an error, so a rite whose search can stand still or go
+          backward would silently loop candidates in place or resurrect an
+          already-superseded occupant rather than failing loudly. The call
+          must also {b terminate} on its own: {!Calendar}'s round guard
+          (calendar.ml's [max_transfer_rounds]) bounds how many ROUNDS the
+          whole-year placement pass takes, which is a distinct, outer thing
+          from whatever internal search a single call to this function runs
+          -- an implementation that walks forward day by day looking for an
+          admissible date, without its own bound, can hang the caller
+          outright on a rite/data shape it does not handle, never reaching
+          the round guard at all. See rite_ef/precedence_ef.ml's
+          [transfer_target] for a concrete termination argument (a
+          structural step bound, not an appeal to the real calendar's own
+          structure). *)
 }