Change order and ASI histories as licensable process records

Why change histories count as process records#

Change order and ASI histories count as process records because each one documents how a project team handled a change: what triggered it, what the architect decided, how the contractor priced it and what the owner approved. Few other records show a professional judgment and its consequence in such a compact, dated form.

AI developers building tools for construction administration, document review and project controls look for exactly this kind of sequence. A drawing revision on its own says little; a revision tied to the question that caused it and to the cost and schedule effect that followed shows a decision made under real constraints.

The chain from RFI to ASI to change order#

The change chain runs from a question to a priced, approved change, and its value depends on keeping every link. Not every change passes through every step, but a typical sequence looks like the one below.

Firms that number ASIs and bulletins in one sequence and cross-reference the originating RFI make the chain easy to rebuild years later. Firms that issued revisions by email alone often find the chain broken at the second or third step.

• 1A contractor submits an RFI about a conflict, a missing dimension or a field condition.
• 2The architect answers in writing, sometimes with a sketch or a reference to existing sheets.
• 3If the answer changes the work, the architect issues an ASI or bulletin with revised sheets, often on an AIA G710 form or in a Procore or Newforma log.
• 4The owner issues a proposal request, or the contractor prices the change in a change order request.
• 5The owner approves a change order, or directs the work through a construction change directive while the price is settled.
• 6The change is closed with its final cost and time effect recorded.

Where each link lives in an architecture firm's systems#

Each link in the chain usually lives in a different system, which is why change histories are rarely as complete as firms assume. The table shows where architecture firms typically find each record and which fields carry the link to the next one.

The last row is easy to overlook. When an owner change also changes the firm's own scope, the additional services record in Deltek or BQE shows the design effort behind it and ties the change history to the firm's project management records.

Fields to keep, generalize or remove#

The fields to keep are the ones that explain the change; the fields to remove are the ones that identify people, parties and money. Generalizing sits between the two and preserves useful structure without revealing who or where.

Apply the rules to free text as well as structured fields. RFI questions and responses often name the owner's representative, the superintendent or the street address inside the body text, which a field-level rule will miss.

Reason codes make a change history more valuable#

Reason codes make a change history more valuable because they turn a list of changes into a record of why projects change. Common categories include owner-requested changes, unforeseen field conditions, code or authority requirements, value engineering and coordination between disciplines.

One category needs care. Changes coded as design errors or omissions can be sensitive for the firm's professional liability position, and some firms code them differently or not at all. Ask counsel and the firm's insurer whether those records should be excluded, generalized or kept before any scope is set.

If the firm never used reason codes, they can sometimes be added during preparation from the RFI and ASI text. That work should follow written rules so the same kind of change is classified the same way every time.

Who controls the change record?#

The architect usually controls its own RFI responses, ASIs, bulletins and revised sheets as instruments of service, subject to the client contract. Under the AIA B101 form, for example, the owner receives a nonexclusive license to use the architect's instruments of service for the project itself, which is a narrower grant than ownership. The contractor's pricing, the owner's approvals and anything held only in a contractor's Procore account are other parties' records.

In practice, a licensable change history often consists of the firm's own logs and responses, with cost and time outcomes reduced to fields the firm recorded itself. Where the contract transfers ownership of documents to the client, or a confidentiality clause covers construction administration records, the project stays out unless the client agrees in writing.

Illustrative: a retail and light industrial practice scopes its change logs#

Illustrative: a fictional architecture firm that designs grocery stores, neighborhood retail centers and light industrial buildings reviews its construction administration records. Its own Newforma logs number RFIs, ASIs and bulletins in linked sequences, while on many projects the contractor's Procore account holds change orders the firm can view but not export.

The CEO approves a scope built from the firm's own logs on projects under its standard agreement, with reason codes added from response text under written rules. Contractor-hosted logs, projects with client confidentiality clauses and changes coded as design omissions are excluded. Client names, contractor names and change amounts are removed, and time impacts are kept.

How SourceX handles change histories#

SourceX handles a change history package through the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The opening fit check works from descriptions of the logs, such as their types, the years they cover and the fields that link them, so no log entries leave the firm.

When a firm goes ahead, the rights review separates firm-controlled records from contractor and owner records, preparation applies the keep and remove rules above, and the SourceX Evidence Packet records what was included, what was removed and who approved the release.