A few places in the spec refer to public API methods:
The DOMRect corresponding to the target’s getBoundingClientRect().
Let boundingClientRect be the value of target.getBoundingClientRect().
For each observer in node’s internal [[RegisteredIntersectionObservers]] slot, invoke unobserve() on observer, passing in node as target.
This is not quite the right thing to do, since it implies that e.g. if I do Element.prototype.getBoundingClientRect = () => { throw new Error("boo"); }
, you'll call that overriden function.
Instead, the correct thing to do is to refer to the backing concept or algorithm behind that method. For unobserve, you'd probably define something in the processing model like
"To remove an intersection observer o from an Element target, perform the following steps: ..."
Then unobserve() algorithm would do "Remove the intersection observer this from target," and instead of doing "invoke unobserve()," you would do a similar thing.
For getBoundingClientRect(), things are more annoying, since CSSOM View hasn't factored themselves appropriately. There you could do something like "Let boundingClientRect be a DOMRectReadonly obtained by the same algorithm as that of Element's getBoundingClientRect() performed on target."