iWorQ's property history needs parcel-change lineage

Give the property chain a stable local identity

iWorQ says its permit-management system ties permits to properties so staff can see past permits, inspections, and code cases, and it describes access through a parcel map. Those statements support a provider-presented current property-history view. They do not establish that an implementation preserves the ancestry of a property record when the real-world site or an upstream parcel system changes.

Create a durable local property node that is not merely today's parcel number or formatted address. Record the jurisdiction, internal property-chain identifier, source-system identifiers, parcel identifiers, situs and mailing addresses as observed, legal-description reference where the authority permits, geometry reference, effective interval, record status, source, observation time, confidence, and custodian. Attach permits, inspections, code cases, licenses, complaints, documents, and other authorized records to the property node valid at the time of the event rather than moving every historical event to the newest label.

Represent every split, merge, and correction

Treat a parcel split or merge as a dated relationship among immutable nodes, not an overwrite. Preserve predecessor and successor identifiers, relationship type, effective date, recording or authoritative source, geometry or allocation evidence where available, responsible reviewer, uncertainty, and superseding correction. One predecessor may have several successors and several predecessors may form one successor. The history view should show that graph without claiming that every prior permit or case belongs equally to every resulting parcel.

Address renumbering, annexation, jurisdiction transfer, demolition, rebuild, condominium creation, lot-line adjustment, duplicate consolidation, and erroneous parcel correction need the same chronology. Distinguish a new identifier for the same continuing property context from a materially new property node, and retain the decision and evidence. When the correct relationship is unknown, leave an explicit unresolved link with owner and review date; a confident but invented lineage is worse than a visible gap.

Keep ancestry separate from nearby data controls

Parcel ancestry answers which earlier local property records precede which later records and which historical events belonged to each node at the time. It is not the same as proving an OGC parcel-service integration, resolving address identity under an FGDC-style address model, documenting ISO-oriented map metadata, or defining the classes and mappings used in a Clariti migration. Those controls can supply inputs, but none alone establishes the persistent predecessor-successor chain analyzed here.

Keep inspection workflow separate too. A property's history may display inspection requests, appointments, visits, results, cancellations, and notices, but the ancestry record does not decide any of those states. It supplies historical property context and preserves which node the event referenced. Similarly, moving data into a new system does not prove that lineage survived; reconcile counts and identifiers, then sample chains across predecessor and successor nodes to prove the relationships and event attachments remained intact.

Demonstrate one property across structural change

A buyer demonstration should start with one parcel and its permits, inspections, and code cases, then split it, merge one successor with a neighboring parcel, change an address, correct a mistaken link, demolish a structure, and create a replacement property context. Reviewers should navigate both forward and backward, see the effective dates and sources, identify records that stay only with one branch, find unresolved relationships, and export the chain without losing predecessor identifiers or chronology.

Civic Permit Review reviewed the registered iWorQ permit-management page on September 7, 2026. It supports the provider's statements about property-linked permit history, past permits, inspections and code cases, and a parcel-map view. It does not establish any customer's parcel identifiers, address match, predecessor-successor relationship, geometry, migration, record completeness, inspection result, jurisdictional decision, permit status, or outcome. The page schema reports datePublished 2019-09-12T16:53:24Z and dateModified 2026-09-03T23:04:31Z, both before the verified cutoff; the recheck established no later material product change.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Civic Permit Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.