Module unit
Exactly the published stages and gates, with human approval at every handoff.
Overview · Modules · Pipeline Board
What it is
The pipeline board is where deals move. It renders exactly the published configuration for the tenant: the stages, the gates between them, and the filters that cut the view. Nothing on the board is hard-coded; an administrator who changes the pipeline changes data, publishes it as one versioned set, and the board renders the new shape. The same truth is available two ways, as a list and as a board, and they are presentations of one underlying state, never two states.
Movement through the pipeline is workflow-by-handoff. A deal crosses a gated stage boundary when a human approves the handoff. That is a deliberate design position, not a missing feature: the pipeline is the accountability rail of the product, and a recommendation, however confident, never moves a deal on its own. The single exception in the entire product is the buy-box auto-reject, which is configured explicitly per tenant and records its reasons when it fires. Every deal, whatever its asset class, ends in one of three shared terminal outcomes. Sharing the terminal vocabulary across asset classes is what lets the rest of the platform reason about outcomes without knowing pipeline internals.
The questions it answers
For the operator: where is every deal right now, what is waiting on my approval, and what left the pipeline and why.
For the investor evaluating us: how does this team keep humans accountable for pipeline movement while still letting an agent work, and how does one codebase serve differently shaped pipelines without code changes.
Scope and boundaries
The unit owns stage state, gate approvals, and terminal outcomes for deals. It does not own the deal's substance: reports, findings, fields, and underwriting live in their own modules, and the board reaches them only through their public contracts. Boundaries share identity, never models. The deal the pipeline moves and the property the analysis engine studies are the same identity but different concepts, and the pipeline never reads another module's tables.
It is not a task manager. Tasks, notes, and documents belong to the deal workspace. The pipeline holds exactly the movement state and the accountability record for that movement, and nothing else, because a board that tries to be a to-do list stops being a trustworthy record of where deals actually stand.
The contract
What it is responsible for, the one door through which state changes, the facts it announces, what it guarantees, and what it refuses. Field-level and schema-level detail is withheld by design; it is held at Tier 2.
The unit owns the movement state of every deal: which stage it is in, which gate approvals have been given and by whom, and which of the three terminal outcomes it reached, if any. It owns the rendering of that state as a list and as a board, both reading the same truth. It renders the tenant's published pipeline configuration and nothing else. It keeps the accountability record: every stage change carries who or what caused it and, for the one automatic mover, the recorded reasons.
Like every module, the pipeline has one write door, and its commands are named by the business action, not by the storage operation. At this altitude we describe them as the actions they perform, not as exact identifiers:
What matters at this altitude is that humans and the agent use the same door under the same rules, and here the rules themselves exclude the agent: gate approval is a human accountability act, so an agent's attempt at either action refuses at the door. Same door, same rules means the refusal is enforced at the door, traceable like everything else, not that the agent can operate it. Agents get the door, never the tables.
Withheld by design Tier 2
The exact command names, their arguments, validation rules, and the shapes behind them are held at Tier 2.The unit announces business facts, and an event carries identity plus the fact, never a data dump. In plain words, it announces that a deal changed stage, that a handoff was approved, and that a deal reached a terminal outcome. Downstream modules react to these facts without reaching into pipeline storage, which is what keeps the boundary real rather than declared.
What done means
Done is not the board rendering once on a developer machine. Done means the live surface holds up against the real backend in all four states: loading, empty, error, and content. It means every load-bearing rule of the unit is expressed as code, a typed contract, a server-side check, or a failing test, never as prose in a document that nothing enforces. And it means the unit has passed both review passes: the program review, which asks whether the code keeps every promise in the cases that would break it, proven by real tests; and the code review, which asks about security, understandability, and consistency with the codebase.
An empty stage renders as an empty stage; we do not pad the board to look busy. A deal awaiting an approval shows that it is waiting at a gate, because the pipeline is an accountability rail and hiding the wait defeats it. Error states are explicit states, designed and reviewed like content states, not fallthroughs. And when a deal leaves the pipeline, the outcome says which kind of leaving it was: a pass worth revisiting is honestly different from a final one, and the record keeps the difference.
Where it connects