Module unit
The zero-question front door: an address in, a deal created, a verified identity every downstream module shares.
Overview · Modules · Intake and Verification
What it is
Intake and verification is the front door of the platform. It exists to turn a raw address, arriving from any of several entry paths, into a single verified address identity that every downstream module can trust. The founding design choice is the zero-question front door: the first address a user gives us creates the deal and lands them directly on it. We ask for the address and nothing else, because every question we could ask at the door is a question the platform should be answering, not the user.
Addresses arrive by more than one path. A user types one in. On the internal operator lane, a deal arrives by inbound email, or through a guarded public form path whose protections (a bot challenge, server-side validation, address dedupe, and submitter binding) stand between the open internet and the backend. Whatever the path, the output is the same thing: one verified address identity, and one deal.
The questions it answers
For the investor or operator, this unit answers: is this the property I mean, and can the rest of the platform now work on it without me re-entering anything.
For the technical reader, it answers a quieter question: where does identity begin, and why does nothing downstream ever re-derive it.
Scope and boundaries
The unit owns the entry paths, the checks that guard the public form path, and the production of the verified address identity. That identity is the boundary artifact. We hold to the rule that a property is not a property: the same address is a different concept to intake, zoning, valuation, market, underwriting, and pipeline, and modules share identity, never models. Intake therefore hands downstream modules an identity, not an object they can reach into. There are no cross-module table reads here or anywhere else; consumers go through published contracts.
The public form path, with its submitter binding, and the inbound email path exist on the internal operator lane only. The lanes fork at the infrastructure layer, never in code, so this is a configuration fact, not a second implementation.
This unit is not a lead-generation CRM. It does not nurture, score, or market to the people behind submissions. It is also not where analysis begins; it ends precisely where the verified identity is handed to the analysis engine, and it holds no opinion about the property beyond the fact of its identity.
Withheld by design Tier 2
Deeper interface detail, including the concrete request handling at the edge and the dedupe behavior at the margins, is held at Tier 2 and available on request.The contract
What it is responsible for, how writes enter, what it announces, what it guarantees, and what it refuses. Deliberately no fields, no schemas, no payloads; that level of detail is held at Tier 2.
The unit is responsible for accepting an address from any supported entry path, guarding the public form path against junk, abuse, and duplicate submissions, producing the verified address identity, and creating the deal that identity belongs to. It owns its own tables by convention and exposes a strict public API; nothing else in the platform reads its storage.
Acceptance and verification are one unit because an accepted-but-unverified address is not something any downstream module is allowed to see. A boundary between the two would carry nothing but half-finished work, which is no boundary at all.
Like every module, intake has exactly one write door, and its commands are named by the business action they perform, not by the storage operation they cause. The door admits a small set of business-named commands covering the entry paths (typed addresses, inbound email deals, and public form submissions, the latter two on the internal lane only) and the act of verification itself.
Each command enforces its own preconditions at the door. The door is the same for every principal: a human on a surface, an import path, and the agent all enter here, and the provenance rules decide what each is allowed to land on. Agents get the door, never the tables.
Withheld by design Tier 2
The command roster is held at Tier 2.When something true happens, the unit announces it as a business fact carrying identity plus the fact, never a data dump. In business language: a deal was created, and an address identity was verified. Downstream modules react to these announcements; nothing polls intake's storage, because nothing can.
What done means
Done for this unit is not "the form submits". Done is the front door holding its guarantees under the traffic that would break them, proven the way we prove everything: load-bearing rules expressed as code, never prose, and a live surface that holds up against the real backend in all four states: loading, empty, error, and content.
Before this unit ships, it passes the same two review passes as every unit. The program review asks whether the code keeps every promise in the cases that would break it, proven by real tests, which for intake means the hostile and ambiguous cases below, not the happy path. The code review asks the ordinary questions of security, understandability, and consistency with the codebase. The writer of the unit is never its auditor; verification is independent and adversarial by standing rule.
The specific promises the gates hold this unit to: the public form path dedupes addresses and survives hostile traffic, verification is the only exit, provenance is stamped on entry, tenant is stamped on every record, and the disabled state is genuinely dead.
Each of these, observed in review or in a test, fails the build:
The unit's honesty obligations are about what it says when the world is messy, because the front door is where ambiguity arrives first.
When an address cannot be verified, the unit says so plainly rather than passing along a guess; there is no downstream path for the unverified. And when this unit refuses a submission, it holds to the bar every error state on this platform is held to: the error names the exact blocker and the fix, because error paths are designed, not caught.
Withheld by design Tier 2
The margins of these behaviors, including how near-match addresses are resolved, are deliberately not specified here; that detail is held at Tier 2.Where it connects