operating-model / loops/operator-loop/listings.md
id: operator-loop.listingstype: domainstatus: activeversion: 2.0loop: operator-loop

Domain · Listings and unit publishing

What it covers

The ongoing management of what appears on the marketplace. This is continuous, not one-time. Operator inventories change — new units come on, existing units update, units get removed and re-listed. The marketplace must reflect reality.

This domain has a first-class downstream dependency: the perfect-fit alert operation in the Renter Loop. Speed and quality of new-unit publishing directly determines whether Rentiful can deliver on the concierge promise to renters. Publishing latency is no longer an internal quality concern only; it is a defining-feature dependency. See ADR 0003 — Concierge as defining feature.

Activities

  • Publishing new units as operator inventory grows — with speed and completeness treated as a concierge-quality requirement.
  • Updating existing units — descriptions, photos, amenities, policies.
  • Availability management — calendars must reflect what is actually rentable.
  • De-listing units that are no longer available or offered.
  • Re-listing units when circumstances change.
  • Bulk actions — handling operator-wide changes (e.g. price changes across a portfolio).
  • Surfacing newly-published units to the Renter Loop in near-real-time.

Operations

New-unit publishing operation

Operator adds unit to source system → ingested by Rentiful → enrichment and validation applied → ready-to-publish review → unit goes live or gets flagged for resolution → publication event emitted for the Renter Loop to consume in near-real-time.

Target: minutes from operator publication to renter-alertable state. This operation is a defining-feature dependency — perfect-fit alerts depend on it.

Update propagation operation

Operator changes a unit attribute → change ingested → validation applied → change propagated to live listing → audit trail logged → change event emitted for the Renter Loop. Continuous, automated by default.

Availability sync operation

Operator's availability calendar updates → ingested → mapped to Rentiful availability model → conflicts flagged → live listings updated. The most volatile operation; runs continuously.

De-list and re-list operation

Unit removed from source or marked unavailable → de-listed from marketplace → reason logged → re-list trigger established (date-based, condition-based, or manual) → unit returns to live when trigger fires → Renter Loop notified of state changes.

Bulk-action operation

Operator-wide change requested (price, policy, availability rule) → impact preview generated → operator confirms → change applied across affected units → audit trail logged → change events emitted for the Renter Loop.

Notes

Listings is the domain where the gap between automation and manual work matters most. Manual listings management does not scale past a few operators. Automation must be in place ahead of operator volume, not behind it.

The elevation of new-unit publishing speed from "internal quality bar" to "downstream dependency" changes how this domain is prioritised. Publishing latency is now measured directly: time from operator-side publication to Renter-Loop-consumable state. The target is minutes, not hours. This is a platform implication as much as an operational one — the platform must support event emission that the Renter Loop can subscribe to (see platform.unit-index).

Cross-loop surface

Comment on GitHub →