Rentiful — Organisational Specification

This repository is the working specification for how Rentiful is organised and how it operates. It is the source of truth. The polished Word documents published periodically are snapshots generated from this repo, not the other way round.

How this is structured

The organisation is described as a set of loops — full accountable chains from signal to closed outcome, each owned by one person end-to-end. Loops are made of domains, domains are made of operations, and operations are where strategy meets execution. Where commercial models differ (e.g. standard marketplace vs White Label), those are vehicles that sit orthogonal to loops.

Journeys sit orthogonal to the spine. A Journey is a goal-directed, ordered composition of Operations within a Loop, used to define progression toward a specific outcome. Journeys reference Operations across one or more Domains; they do not own or contain them. Journeys do not introduce ownership and do not execute work themselves — the Loop owner remains accountable, Operations execute, and the Journey defines what "correct progression" looks like and what must happen if progression stalls. The first three are Renter-Loop journeys: Viewing, Concierge, Closing.

Everything uses consistent vocabulary. The vocabulary is defined in loops/renter-loop.md#vocabulary.

Index

Loops

operator-loop — supply, onboarding, unit quality, diagnostic feedback (primary)
renter-loop — demand, conversations, matching, conversion, revenue attribution (primary)
platform-loop — infrastructure that the primary loops run on
financial-loop — invoicing, reconciliation, cash, reporting
fundraise-loop — investor relationships and capital
strategy-loop — company-level direction and resource allocation

Commercial vehicles

standard-marketplace — listings on rentiful.ai, commission on signed leases
white-label — co-branded operator microsite, £0 upfront, £750 per signed lease

Decisions (ADRs)

Cross-cutting

cross-loop.md — dependency graph across all loops

Loop metrics

renter-loop/metrics.md — north-star, CAC convention, three-layer telemetry (funnel / process-quality / outcome-quality)

Journeys (Renter Loop)

viewing-journey — qualified intent → resolved outcome (application / rejected / re-matched / rescheduled / closed unsuccessful)
concierge-journey — operational expression of ADR 0003: Learn → Monitor → Share → Feedback
closing-journey — positive viewing decision → lease signed → cash received (crosses Operator and Financial loops)

Conventions

One file per domain. A loop's top-level overview lives at loops/<loop>.md. Each domain lives at loops/<loop>/<domain>.md (e.g. loops/renter-loop/matching.md). This keeps any single file readable and makes diffs meaningful.

Frontmatter is queryable. Every file has YAML frontmatter with at least id, type, and status. Files that describe operations also carry signal, closed_state, and depends_on in a structured operations: list so that tooling (or an agent) can reason about them without parsing prose.

Stable identifiers. IDs use dot notation: renter-loop.matching.perfect-fit-alert refers to the perfect-fit alert operation inside the Matching domain of the Renter Loop. These are the names used in cross-references and should not be changed without a deliberate rename.

Narrative alongside structure. The frontmatter captures what a machine needs; the body captures what a human needs — the why, the rationale, the failure modes. Both matter. Neither is sufficient alone.

ADRs capture decisions, not status. When a significant structural call is made (e.g. co-branded White Label over operator-fronted), it gets an ADR. ADRs are immutable once merged; if a decision is reversed, a new ADR supersedes it.

Versioning. The spec evolves. The repo's commit history is the version history; snapshot publications to Word/PPTX are tagged. Files carry a version in frontmatter for human-readable reference.

From concept to production

Each operation in this repo is a candidate for automation. The frontmatter fields signal, closed_state, depends_on, and automation are the contract an implementing agent would satisfy:

Signal → trigger binding (event stream, schedule, inbound message, threshold)
Closed state → testable post-condition (the agent's definition of done)
Depends on → required upstream operations or platform capabilities
Automation → current level (none, partial, high, full) and the direction of travel

Operations marked automation: full are fully delegated to agents; high means the agent runs the operation with human escalation at defined points; partial means the human runs it with agent assistance; none is pure human work. The aim is that automation values tend upward over time as operations are hardened and agents gain the tools they need.