Data methodology
How the data is built, and what it can be relied on for.
Every figure in 718 Interchange comes from a public record that somebody else published. This page explains what happens between that record and the screen, so you can judge the result before you act on it.
Last updated September 10, 2026
The standing disclosures
Seven One Eight Systems organizes information from official public records and other authorized sources. We are an independent technology company and are not affiliated with or endorsed by any government agency.
Public records may be incomplete, delayed, corrected, or inconsistent across sources. Verify material decisions against the cited source record.
Inferred relationships are research signals, not legal determinations of ownership, control, affiliation, licensing, compliance, or eligibility.
From source record to screen
Nine steps sit between an agency's publication and what you search. Each one can introduce a difference between the record and the row, so each is described here rather than summarized as “processing.”
-
Collection
We read 45 published sources on a fixed schedule — open-data APIs, agency portals, and public search systems. We read what the agency publishes; we do not scrape private systems, buy personal data, or obtain records through anything other than the public route. Each read is stamped, and the stamp is what the workspace shows you as freshness.
-
Normalization
Source fields are mapped onto a consistent shape: dates parsed into real dates, boroughs and block-and-lot numbers into a single parcel identifier, statuses into the source's own vocabulary rather than a new one of ours. Company and person names are normalized for comparison — case, punctuation, and entity suffixes such as LLC or CORP — while the name as filed is kept and displayed. You always see what the agency wrote.
-
Deduplication
Sources republish. Most agencies release a full dataset each cycle rather than a change feed, so the same record arrives many times. Records are keyed on the source's own identifier — a job number, a document id, a ticket number — and a repeat read updates that record instead of creating a second one. Where a source publishes no stable identifier, the key is built from the fields that identify the filing, and that is a design decision we will tell you about for the source in question.
-
Entity matching
Two records naming the same company are grouped by comparing normalized names, and in some places by an identifier the sources share, such as a licence number or a PASSPort Supplier ID. An identifier match is reliable. A name match is not. Records are never merged into a single “resolved entity”: each keeps its own history and its own link back to the filing it came from.
-
Geocoding
Locations come from the City's own address directory, which maps an address to a borough-block-lot and a building number. That directory is republished quarterly and carries no coordinates of its own, so a brand-new building can be permitted before it is listed. Records that cannot be placed are shown in lists and left off maps rather than being placed approximately. A map view therefore covers a subset of the records behind it, and says so.
-
Cross-source linking
A parcel joins records across products reliably, because the parcel identifier is the same number in every city dataset. A company does not: no shared key exists between, say, a DOB filing and a procurement award, so those links are built on names. Trust the individual record over the page that groups it.
-
Refresh
Every source has a published read cadence and a published expectation for how far behind the source's own data may run. Both are in the Data Coverage table. When a source falls outside its expectation, the workspace marks it delayed on the page rather than showing a stale figure as current.
-
Quality checks
A read that returns implausibly few rows does not replace the data it would have overwritten. Row counts, the date a source runs through, and the time of the last successful read are recorded per source and surfaced in the product. Changes to existing records are found by comparing each read against the previous one, and corrections we make on our own side are excluded from those change feeds so that our fixes do not appear as agency activity.
-
Correction handling and retention
Public records are themselves corrected and withdrawn. When a source revises a record we take the revision on the next read; when a source removes a record, we remove it too. We do not maintain a private archive of records an agency has retracted. Reports of a bad entity match are handled individually — see below.
Four kinds of field, and how to tell them apart
Not everything on a record page has the same standing. These four categories behave differently, and the difference matters most when you are about to rely on one.
Source-provided
Printed in the record as the agency published it: a job number, a filing date, a party named on a deed, an awarded amount. If we show it differently from the source, that is a defect. Report it.
Normalized
The same fact in a consistent shape — a parsed date, a parcel identifier assembled from borough, block and lot, a name stripped of punctuation for comparison. No new information is added. The value as filed remains visible.
Calculated
Arithmetic over records we hold: filing counts, totals, rankings, period-over-period change, days elapsed. Correct for the records in scope, and only ever as complete as that scope.
Inferred
A relationship no single record states: that two filings involve the same company, that a sale preceded a renovation. These are never presented as recorded fact.
How matching works, and its limits
Company, owner and party pages group records whose names match after normalization, and use a shared identifier where the sources carry one. A grouped page is a convenience, not a finding: open the individual records before you rely on a total. If a record is grouped with the wrong company, email hello@718systems.com with its job number, document id or ticket number and we will correct it.
Two limits we will not paper over. There is no perfect entity resolution for New York public records: agencies share no company identifier, and the same firm files under spellings that differ by a comma. A grouped total is the output of a stated rule, not a judgment about who owns what.
And nothing here identifies a person behind an entity unless a public record names them. New York filings carry no LLC member names at all, so an absent officer is the norm rather than a gap, and a registered agent is not an owner.
What public records cannot tell you
Public records are incomplete, delayed, corrected after publication, and inconsistent between agencies that describe the same thing. This is a property of the records, not of the product, and no amount of processing removes it. Some consequences worth carrying into a decision:
- Absence is not evidence of absence. A search returning nothing tells you about the sources listed in Data Coverage. Work filed with a body we do not read, or in a legacy system an agency has retired, is simply not there.
- A status is as of the last read. Nothing on a page is a live query against the agency. A deadline, a licence, or an open balance should be confirmed at the source before you rely on it.
- Most sources record intent, not completion. A permit is authorization to begin. An abatement notification is filed before work. An accepted offering plan is not a building. Few feeds carry a verified completion date at all.
- A complaint is not a finding, and a violation is not a judgment about a current owner. Enforcement records attach to a building and a name, and can predate a sale.
- Amounts are as filed. Job values, quantities and estimated contract values are what the filer entered. No agency in these sources independently verifies them, and neither do we.
Verify material decisions against the cited source record. Every record in the product links back to the agency's own posting for exactly this reason. Bidding, lending, contracting, hiring and compliance decisions should rest on that document, not on an aggregated page.
Questions about any of this
If a figure looks wrong, a match looks wrong, or you need to know whether a particular source is in scope before a demo, write to hello@718systems.com. Specific questions get specific answers — including “we do not cover that.”