I think for the docs rather than only refer to "weighting" I might mention that this would usually be counts of a particular linelist item (i.e. connecting it up to the data rather than abstractly it's a weighted likelihood -- I'm unsure under what circumstance someone would be weighting in a way unconnected to counts of an observation).

I agree the documentation isn't super clear, but I think it can be polished up with some edits to the details, and an example. I don't know that a full vignette is needed.

Agree that a full vignette is not needed for this alone. That said, I do think we should have a vignette / paper about the marginal model (and its differences as compared with the latent model) and it'd naturally be included there about how to use this argument.

I'm going to take a stab at a good-enough fix now.

See the updated documentation on main. This may or may not resolve the issue for you.

Agree makes progress and don't mind about closing.

IMO still could have mention of it in weight here:

Linking to concepts like:

The result is a more compact representation of the same data where each row represents multiple identical observations with the count stored in the n column.

Could be useful to include the description here which I think has the context?

FWIW find things like the below to be quite visually cluttered. I think it's going to be confusing for users. I agree with there being downsides on other approaches too, just to say it's a lot.

I think that probably requires it own issue for more structure in the pkgdown yaml which might help

Could be useful to include the description here which I think has the context?

The description is:

This method converts linelist data to a marginal model format by calculating delays between primary and secondary events, along with observation times and censoring windows. The likelihood used is imported from the primarycensored package which handles censoring in both primary and secondary events as well as truncation due to observation times. In principle, this method should be more accurate and more computationally efficient than the latent model (as_epidist_latent_model()) approach in most setting except when the number of unique strata approaches the number of observations.

Maybe this helps a bit. Feels like you would want to directly say the argument weight and how it fits in. Might reword "In principle, this method should be more accurate and more computationally efficient than the latent model" (this is a method to prepare data, feels like a type error to call it efficient, it's the model that is efficient or not).