Carry the observation exposure into a count prediction

Specify the observation opportunity

Cornell’s count-model guidance, checked 7 November 2026, describes a log-exposure offset with coefficient fixed at one and the resulting proportional-exposure assumption. The observation opportunity might be time or another justified quantity. The analyst must establish that this is appropriate before the implementation is accepted.

List what one row counts, what opportunity accompanies it and the unit of that opportunity. For an invented event-support desk, a row might count repeat requests during a documented observation period. Keep closed hours and missing observation separate from recorded zero events. A broad calendar duration is not automatically the time during which requests could actually be observed.

Ask the analyst whether the recorded outcome can recur within that opportunity and what dependencies require consideration. Do not treat all bounded success counts or every percentage as the same kind of count-model problem. The business label volume is not a specification. This lesson assumes an approved model and checks its input/output contract rather than selecting a statistical family.

Keep raw exposure distinct from an additive offset

The statsmodels Poisson.predict documentation, checked 7 November 2026, adds offset directly to the linear predictor but logs exposure first. When new exog is supplied, the documented defaults are zero offset and unit exposure. Verify the deployed version and explicit arguments; the names are not interchangeable.

Use an original known-answer fixture with supplied baseline expectation of two events per hour and all other conditions held fixed. Four hours should produce eight expected events under the stipulated proportional model. The implementation can represent the four-hour opportunity through its correct exposure route or its corresponding logarithmic-offset route. Have the technical owner identify which interface is actually used instead of passing both to be safe.

Test the same fixture using the new-input path that the dashboard will call. If it omits the four-hour exposure and uses the documented unit default, it returns the one-hour quantity of two rather than eight. This can look like a successful numerical prediction because no missing-value marker appears. Compare the returned meaning, not just the presence of a number.

Use a deliberately wrong input to expose the boundary

For the fixed fixture, the linear predictor at one hour is the natural logarithm of two. Supplying raw four as the additive offset produces two multiplied by exp(4), approximately 109.20, rather than eight. This intentionally wrong case reveals a representation error. It is not evidence of a sudden increase in demand and should not trigger a business response.

Ask the technical owner to provide the corresponding correct result with the logged value in the additive route, and then with the raw value in the exposure route. Both should reproduce the agreed fixture once, not compound the same opportunity twice. Record the exact field names and units from the supplied implementation evidence. Do not modify live settings or infer that every library uses the same interface.

Include a request with changed covariates and unchanged exposure so the test does not pass only when original training inputs are reused. Require an explicit route for missing, invalid or unknown observation duration. Filling such a field with one changes the question and should not masquerade as recovered evidence.

Label the returned quantity at the decision point

Have the analyst identify whether the output is an expected count for the specified opportunity or a rate per unit. Preserve that label through exports, dashboard cards and any aggregation. A four-hour expectation should not be labeled events per hour without the appropriate calculation and interpretation. Display rounding belongs after the underlying quantity is verified.

Keep the fixture, argument record, version and permitted-use statement together. Recheck them when the prediction wrapper changes, even if the fitted parameters do not. An input omission can alter the result without a model retraining event. The accepted contract does not establish model accuracy, proportionality in every setting or a causal effect of changing operating hours. It prevents a specific observation-unit mistake from entering a planning recommendation.

Make the reasoning concrete.

A fictional dashboard requests a four-hour event count while sending only new covariates. The supplied interface uses its one-unit exposure default, and the card presents the returned two as the full-period expectation.

The reviewer records the argument omission and requests the corrected test evidence. No real forecast, staffing commitment or deployment is performed.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Opportunity

   What duration or other justified exposure does one row represent?

2. Representation

   Which interface receives raw exposure and which receives a transformed offset?

3. Fixture

   Does the four-hour request reproduce the expected eight?

4. New inputs

   Does the actual new-covariate route preserve the supplied opportunity?

5. Output

   Is the displayed number a period count or a per-unit rate?

Watch for the wrong conclusion.

• Treating raw exposure and an additive offset as interchangeable fields.
• Omitting the observation opportunity when supplying new prediction inputs.
• Using a successful numerical response as proof of correct units.

Sources & scope

All business examples and numerical fixtures are original and fictional. Sources support the identified mathematical or implementation distinctions. Qualified analysts own model specification and inference. No causal result, model fit, actual customer data or operational change is claimed.

• Cornell Statistical Consulting Unit: To Offset or Not, Using Offsets in Count Models →Primary university statistical guidance · Supports: Supports the fixed log-exposure offset and proportionality assumption; the event-desk fixture is original.
• statsmodels.discrete.discrete_model.Poisson.predict →Primary software documentation · Supports: Supports the documented offset/exposure distinction and defaults when new exog is supplied; no universal library behavior is asserted.