What this portal can synchronise

The first call a client makes, and the one every later call is planned against.

Nothing here depends on who is asking: the answer describes the portal, not the caller, and the method reads nothing the caller owns. What it publishes is the schema version, the vocabulary of entities and of changes, the page ceilings, how long the journal of changes keeps a record, how long an interaction keeps an object in sight, and the three polling steps - the shortest one allowed, the recommended one and the longest one still accepted.

interactionWindowDays is the one number that is about the memory of the portal rather than about the journal. An object a user only ever touched - opened through a link, or reached through an attachment of another module - is theirs to see while the window lasts, and is announced as a tombstone once it runs out. Nothing happened to such an object; the portal stopped counting the interaction as a reason to show it.

The numbers are not constants of the product. A portal may shorten the life of its journal, and the polling bounds move with it, so a client that stores them once and never asks again will eventually plan against bounds the portal no longer honours. Ask on every start of a synchronisation cycle.

cardSections names every section the schema declares and says, for each, whether this portal fills it. A section published as false is refused when it is asked for rather than answered empty: an empty section would be indistinguishable from "nothing is there".