<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Modelling — DSAMbayes Documentation</title>
    <link>/modelling/index.html</link>
    <description>Purpose Describe model classes, inference contracts, diagnostics, and decision-layer semantics for DSAMbayes. This section is primarily reference material; use Principled Bayesian Workflow for the methodology spine.&#xA;Audience Practitioners building and interpreting DSAMbayes models. Reviewers validating modelling assumptions and outputs. Pages Page Topic Model Classes BLM, hierarchical, and pooled class constructors, fit support, and limitations Model Object Lifecycle State transitions from construction through fitting to post-fit extraction Priors and Boundaries Prior schema, defaults, overrides, boundary controls, and scale semantics Minimal-Prior Policy Governance guidance for prior specification in MMM Response Scale Semantics Identity vs log response, KPI-scale conversion, Jensen-safe reporting Diagnostics Gates Policy modes, threshold tables, identifiability gate, and remediation actions CRE / Mundlak Correlated random effects for hierarchical models Time Components Managed holiday feature generation and weekly anchoring Budget Optimisation Decision-layer budget allocation, objectives, risk scoring, and response transforms</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <atom:link href="/modelling/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Model Classes</title>
      <link>/modelling/model-classes/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>/modelling/model-classes/index.html</guid>
      <description>Purpose DSAMbayes provides three model classes for Bayesian marketing mix modelling. Each class targets a different data structure and pooling strategy. This page describes the constructor pathways, fit support, and practical limitations of each class so that an operator can select the appropriate model for a given dataset.&#xA;Use this page to choose the right modelling surface for your data structure and decision problem. Do not use it as a substitute for the broader workflow: class selection does not settle prior design, computational trustworthiness, model adequacy, or causal interpretation. For that framing, start with What Principled Means, Stage 2: Model and Priors, and Stage 5: Model Adequacy.</description>
    </item>
    <item>
      <title>Model Object Lifecycle</title>
      <link>/modelling/model-object-lifecycle/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>/modelling/model-object-lifecycle/index.html</guid>
      <description>DSAMbayes model objects (blm, hierarchical, pooled) are mutable S3 lists that progress through a well-defined sequence of states. Understanding these states helps avoid calling post-fit accessors on an unfitted object or forgetting to compile before fitting.&#xA;This page is an API/runtime reference. It explains how DSAMbayes model objects move through construction, compilation, fitting, and post-fit access. It is not the main guide for prior-setting, diagnostics meaning, or model adequacy. For that, use the Principled Bayesian Workflow.</description>
    </item>
    <item>
      <title>Priors and Boundaries</title>
      <link>/modelling/priors-and-boundaries/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>/modelling/priors-and-boundaries/index.html</guid>
      <description>For the workflow guidance behind these controls, start with Stage 2: Model and Priors. This page is the technical contract for DSAMbayes prior and boundary behavior.&#xA;Use this page when you need exact DSAMbayes semantics: supported prior families, override syntax, default generation rules, and scaling behavior. Do not use it as the main argument for why a prior is reasonable. That reasoning belongs in the workflow pages and in your modelling rationale.</description>
    </item>
    <item>
      <title>Minimal-Prior Policy</title>
      <link>/modelling/minimal-prior-policy/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>/modelling/minimal-prior-policy/index.html</guid>
      <description>This page is the short operating rule for prior-setting in DSAMbayes. Use it when you want a compact default policy. For the full workflow logic, see Stage 2: Model and Priors. For the mechanics of YAML and API prior specification, see Priors and Boundaries.&#xA;Purpose Use a principled but low-friction prior setup that avoids specification-hunting while preserving identifiability in short, collinear MMM datasets.</description>
    </item>
    <item>
      <title>Response Scale Semantics</title>
      <link>/modelling/response-scale-semantics/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>/modelling/response-scale-semantics/index.html</guid>
      <description>Purpose DSAMbayes models can operate on an identity (level) or log response scale. This page defines how response scale is detected, stored, and used for post-fit reporting, so that operators understand which scale their outputs are on and how KPI-scale conversions work.&#xA;Response scale detection Response scale is determined at construction time by detect_response_scale(), which inspects the left-hand side of the formula:</description>
    </item>
    <item>
      <title>CRE / Mundlak</title>
      <link>/modelling/cre-mundlak/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>/modelling/cre-mundlak/index.html</guid>
      <description>Purpose The correlated random effects (CRE) pathway, implemented as a Mundlak device, augments hierarchical DSAMbayes models with group-mean terms. This separates within-group variation from between-group variation for selected regressors, reducing confounding bias when group-level means are correlated with the random effects.&#xA;When to use CRE Use CRE when:</description>
    </item>
    <item>
      <title>Time Components</title>
      <link>/modelling/time-components/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>/modelling/time-components/index.html</guid>
      <description>Purpose DSAMbayes provides managed time-component generation through the effects.holidays config section. When enabled, the runner deterministically generates holiday feature columns from a calendar file and appends them to the compiled model formula. This page defines the configuration contract, generation logic, naming conventions, and audit properties.&#xA;Overview Time components in DSAMbayes cover:</description>
    </item>
    <item>
      <title>Diagnostics Gates</title>
      <link>/modelling/diagnostics-gates/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>/modelling/diagnostics-gates/index.html</guid>
      <description>For the workflow interpretation of these checks, start with Stage 4: Computation and Sampler and Stage 5: Model Adequacy. This page is the threshold and policy reference.&#xA;Use this page when you need exact gate thresholds, status aggregation, or YAML policy semantics. It does not replace substantive model review: a model can clear threshold tables and still be a poor basis for interpretation.&#xA;Model selection for time-ordered data PSIS-LOO and WAIC treat pointwise observations as conditionally exchangeable. That assumption is not generally appropriate for time-ordered MMM data, where nearby weeks can remain dependent after conditioning on the fitted model.</description>
    </item>
    <item>
      <title>Budget Optimisation</title>
      <link>/modelling/budget-optimisation/index.html</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>/modelling/budget-optimisation/index.html</guid>
      <description>Purpose DSAMbayes provides a decision-layer budget optimisation engine that operates on fitted model posteriors. Given a channel scenario with spend bounds, response-transform specifications, and an objective function, the engine searches for the allocation that maximises the chosen objective while respecting channel-level constraints. This page defines the inputs, objectives, risk scoring, response-scale handling, and output structure.&#xA;Overview Budget optimisation is separate from parameter estimation. It takes a fitted model and a scenario specification, then:</description>
    </item>
  </channel>
</rss>