Domain · Platform inputs
What it covers
Specifying what the platform needs to do to unblock the loop, and validating that shipped changes work. The interface between the Renter Loop and the Platform Loop.
Activities
- Writing specs for platform changes when the loop is blocked.
- Running the loop manually during the gap between spec and ship.
- Validating shipped changes actually unblock the loop.
- Maintaining visibility into the platform queue.
Operations
Platform spec operation
Signal: Loop blocker identified. Steps: Spec written (problem, current workaround, proposed change, success criteria) → submitted to Platform Loop queue → reviewed in cross-loop sync. Closed state: Spec submitted and reviewed. Cadence: Event-driven.
Ship validation operation
Signal: Platform change shipped. Steps: Loop owner tests against the original blocker → confirms unblock or reopens with diagnosis → updates loop automation to use the new capability. Closed state: Either the blocker is confirmed resolved and automation updated, or the spec is reopened. Cadence: Event-driven.
Standing platform requirements created by this loop
Three platform capabilities are not optional for the Renter Loop to function as designed; they are structural prerequisites.
Unified conversation infrastructure (platform.conversation-infrastructure)
Because conversation is the unit of interaction, the platform must maintain a single persistent conversation thread per renter that can be entered or continued through multiple mediums (email, WhatsApp, web chat, others as added). The conversation must hold state — history, profile, prior matches, prior responses — and that state must be accessible to every operation that operates on it. This is not a feature; it is the foundation the loop runs on.
Near-real-time supply visibility (platform.unit-index)
Because the perfect-fit alert operation depends on matching new units against active renter profiles within minutes of publication, the platform must surface new and updated units from the Operator Loop to the Renter Loop in near-real-time. Latency between operator publication and renter alert is a direct determinant of how well Rentiful delivers on the concierge promise.
Multi-brand conversation infrastructure (platform.multi-brand-config)
Because the Renter Loop operates across multiple branded surfaces — rentiful.ai as the owned surface and White Label microsites as partner surfaces — the conversation platform must support brand configuration per surface. The same operations must render their messages under Rentiful branding on the owned surface, or under operator branding co-signed "powered by Rentiful" on partner surfaces, without duplicating operational infrastructure. This allows one Renter Manager to run one loop across N branded surfaces without operational overhead scaling linearly with surface count.
Notes
The discipline is patience and pragmatism. Platform changes take time. The loop owner runs the loop manually in the gap rather than waiting for the platform. "I'm blocked" is never an acceptable status; "I have a workaround running and a spec submitted" is. The three standing requirements above, however, are not workarounds — they are foundational and need to be in place for the loop's design to be honest.