Set Subject Property Facts
Records the subject property of an appraisal package — address, parcel, size, values — in one place on the package, where later runs and the finished deliverable both read it.
Overview
An appraisal package is thirty-odd pages that all talk about one property. The main report form asks for the address. So does the photo addendum header, the sketch page, the certification, the invoice and the transmittal letter. The gross living area appears in the improvements section and again in the sales comparison grid. The parcel identifier shows up on the report and on the legal certification. When a person types those facts form by form they drift — "St." on page one and "Street" on page fourteen, the county spelled out in one place and abbreviated in another. None of it is wrong exactly, and all of it is the kind of thing a reviewer flags and sends back.
This tool gives the run one answer to which property is this. It records the subject property — the one property the whole package is about — on the package itself, from the documents the appraiser uploaded, instead of leaving that identity implicit in whichever file happened to mention it. It is part of the appraisal workflow; the pre-bid and coating-QA workflows have no subject record and no way to set one.
Each call layers onto the record rather than replacing it. A fact supplied replaces the stored value; a fact left out keeps the value it already had. So a second run can correct one thing without re-sending everything else, and facts can be discovered in whatever order the documents give them up.
Two things read the record afterwards, and the second is the one worth knowing about. Every later run on the same package opens with the recorded facts in front of the agent, so a follow-up supersedes rather than re-derives. And the finished package's page header is built from the recorded address — with no address on the record, the deliverable is assembled and delivered with no header on any page, and the run still reports success. Recording the address is what decides whether the finished report has headers at all.
What this does not do is fill forms. Field values come from the source documents routed to each section — see Fill Sections from Source Documents — and the subject record is not one of those sources.
What It Does
| Capability | What it means for you |
|---|---|
| One subject record per package | Address, city, state, ZIP, county and parcel identifier are recorded once on the package rather than held per form |
| Merge, don't clobber | Repeated calls layer onto the same record: a fact supplied replaces what was there, a fact left out keeps its stored value |
| Progressive discovery | The year built can come from one document and the legal description from another, in any order |
| Party and engagement facts | Borrower and lender or client are recorded on the same record as the property |
| Physical characteristics | Gross living area, year built, bedrooms, bathrooms and lot size are recorded alongside the address |
| Valuation figures | Contract price, as-is value and after-repair value are recorded on the same record |
| Carried into later runs | A later run on the same package opens with the recorded facts in front of the agent |
| Supplies the deliverable's page header | The recorded address is what the finished package's page header is built from |
When the Agent Chooses This Tool
Of the three package workflows, only appraisal has this tool. A pre-bid or coating-QA run cannot call it.
Within that workflow the instructions make the call a fixed step rather than a judgment. There are three rules, and all three are about when, not whether:
- After the uploads are listed, before anything is built. The agent lists the uploads, then records the subject in a single call carrying everything it knows, drawn from the subject tax record, the comps spreadsheet and the notes file. Only after that does it create sections or start fills. The workflow gives the agent an expected shape for a run's tool calls; it counts one of these, as an estimate rather than a cap.
- First, when an upload is an already-filled package. If the appraiser uploads a PDF that is already a filled deliverable, recording the address from it is mandatory and happens before that file is taken apart — even though the fuller call follows later in the same run.
- On a later run, only when that run supersedes the record. Unchanged facts are not re-sent. A correction is superseding data: tell the agent the parcel identifier is wrong and the next run records the corrected value over the old one.
The judgment actually left to the agent is what counts as a subject fact. Comparables are not the subject — the MLS export and the comp tax records are routed to the sales comparison section as source documents, and nothing about them is recorded here.
Inputs and Outputs
Takes: any of the subject property facts the agent currently knows — address, city, state, ZIP, county, parcel identifier, borrower, lender or client, legal description, gross living area, year built, bedrooms, bathrooms, lot size, contract price, as-is value and after-repair value. Every one is optional. Facts the agent does not know yet are left out, and what is left out is not disturbed.
Returns: the merged record as it now stands.
Example
An appraiser uploads a field inspection PDF, subject and comparable tax records, an MLS export, a sales contract and a rehab bid, and asks for a full ARV report package.
The agent lists the uploads, reads the subject tax record, the comps spreadsheet and the notes file, and records the subject in one call: address, city, state, ZIP, county, parcel identifier, gross living area, year built, bedroom and bathroom counts, lot size, contract price, as-is value and after-repair value. Then it creates the sections and starts the fills.
That record is what the delivered PDF's header carries, so every page after the first identifies the property. A week later the appraiser comes back with a corrected parcel identifier and a revised after-repair value. That run opens with the existing record in view; the agent records the two corrections and leaves everything else exactly as it was.
Limits
- Appraisal packages only. The pre-bid and coating-QA workflows have no subject record and no tool that could set one.
- Recording facts does not fill anything. Section fields are filled from the source documents routed to each section, and this record is not one of those sources — so correcting a fact here does not revise a field that was already filled from a document.
- One subject per package. Comparables, secondary parcels and multi-property assignments are not modelled here.
- A fact left out of a call is never cleared; it keeps the value it already had. Correcting a value means supplying the right value.
- Later values win, so a wrong value recorded late beats a correct value recorded earlier. Order matters when sources disagree.
- Nothing is validated. The recorded parcel identifier is not checked against the county, nor the square footage against the tax roll — the record holds what the uploaded documents say.
- Recording an address also renames the package to that address, replacing whatever it was called before.
- With no address on the record, the finished package is delivered without a header on any page, and the run still reports success.
Built for One Workflow
This tool exists because appraisal packages have a subject property. Insurance submissions have an insured and a location schedule; contractor bid packets have a solicitation and a site. The document-level steps — merging, stamping, finalizing — are shared by all three workflows, but the facts that hold a package together differ by vertical, and the tool that records them is registered per workflow.
Which tools each workflow has is fixed when the workflow is built, not decided by the agent at runtime. See /pricing for how workflow-specific tools and form sets are put together, and /solutions/real-estate-appraisal for what the appraisal deployment covers end to end.
FAQ
Why does the same property data need to be set at all if it's already in my documents?
Because your documents are not the package's own record of what it is about. Each of them mentions the property differently, and none of them is what the run reads later. Committing one version gives a follow-up run a starting point it can supersede instead of re-deriving, and it gives the delivered package the address printed in its page header — without it, the package goes out with no header on any page.
What happens if the agent calls this twice with different values?
The calls merge. A fact supplied in the later call replaces the earlier value; a fact left out of the later call keeps the value it already had. That is what lets the year built come from one document and the parcel identifier from another and still end with one record.
Can I correct a value the agent got wrong?
Yes. Tell it the correct value and the next run records it over the old one — and leaving a fact out of a call never clears it, so supplying the right value is the way to fix a wrong one. What the correction fixes is the record, and with it the delivered package's header. Fields already filled from your documents are not revised by it; re-filling a section is a separate step the agent takes when a run brings new information for that section.
Does this store comparable properties too?
No. It holds the subject property only — the one the report is about. Comparable data is routed to the sales comparison section as source documents, from your MLS export and the comp tax records, and is not recorded here.
Does it check the facts against county records or the MLS?
No. It records what your uploaded documents say, and nothing in it is compared against an outside source. Verification stays an appraiser judgment, as does the valuation itself.
Is there an equivalent for non-appraisal packages?
No. Appraisal is the only one of the three workflows with this tool; the pre-bid and coating-QA agents have nothing like it. Other verticals get the tools their workflow needs, built during setup. That per-workflow tooling is what the implementation described on /pricing produces.