Architecture

Per property/room/date the engine runs: demand-signal (occupancy · pace · comp-index · seasonality · weekend · event, fixed-seed) → driver synthesis (each factor a signed Δ%) → clamp to the configured max-swing → clamp to the absolute floor/ceiling band → recommended rate + clamped flag. It is pure and reproducible; there is no model call. The price calendar simply runs this over 14 days.

Reads the shared core (property, room_type, rate_plan, inventory) through the foundation adapter. Writes its own C4 overlay — approved-rate rows and the guardrail overlay — held per credential in the C4Store scope; in Stage-2 these map to demo_eco_* overlay tables via the injected C4Sinks, with the in-memory write still driving instant UX. The data invariant holds: owner writes are canonical (credential null); a viewer's approvals and guardrail edits are credential-scoped, ephemeral, and cleared on reset.

Emits price.updated on approve/override and inventory.changed on generate. The two-layer guardrails (immutable baseline ⊕ owner overlay) are audited and bump a config version that becomes the demand-cache key in Stage-2. Metered AI: none — the demand-forecast stage records a $0 cost_ledger row labelled 'deterministic (rules · $0)' so the inspector trace is honest; there is no demo_cache because nothing is metered.

No real demand forecasting model, no competitor rate-shopping integration, and no real rate publication to external channels — channel sync is handled by the simulated Channel Manager #17. No real imagery, no PII, no proprietary pricing logic or metrics appear anywhere.