Revision Clouds Without Narratives: Why Contractors Set Your ASIs Aside

The Cloud Nobody Acted On

A boutique studio issues an ASI on a fast-moving kitchen remodel: the island outlet locations shift, one cabinet run gets a different filler condition, and a tile transition moves by a few inches. The revised sheets go out with neat revision clouds around each change. Two weeks later, at the site walk, the outlets are in the old locations. The contractor is not being difficult. He opened the set, saw clouds scattered across three sheets, could not tell from the sheets alone what had actually changed or why, set the package aside — and built from the version he already understood.

That sequence is illustrative, not a documented project, but the failure in it is common enough to design against. The studio did communicate. It just communicated only where, and left what, why, and what to do next for the field to reconstruct. A cloud is a pointer. It is not an instruction.

Bottom line up front

• A revision cloud marks the location of a change; a delta triangle ties that cloud to a specific numbered revision; neither one explains the change.
• The missing piece is the narrative: two or three plain sentences, on the ASI and in the sheet's revision block, stating what changed, what it replaces, and what the field should do.
• Under the AIA A201 framework, an ASI — Architect's Supplemental Instruction — is for a minor change that does not adjust the contract sum or the contract time. If a change does affect cost or time, it belongs in a construction change directive or a change order, not an ASI.
• The habit that fixes this is small: no cloud leaves the office without a matching delta and a dated revision description a superintendent can act on without opening a second file.

---

What each mark actually does

Clouds, deltas, and narratives are three different tools, and treating any one of them as the whole system is where ASIs go quiet. A revision cloud is a cloud-shaped outline drawn around the part of a drawing that changed since the previous issue. A delta is the small triangle, carrying a number or letter, placed beside the cloud and keyed to the revision block in the title block — delta, from the Greek letter used to mean change. The revision block is where the issue is supposed to become readable: revision number, date, and a description.

In practice, the third element is the one that gets skipped. The cloud is drawn because the software makes it easy. The delta is placed because common drawing practice — and most office standards — call for it. The description gets left as "ASI 07" or "Revised per field" — which tells the reader nothing they did not already know from the transmittal.

Write the narrative like an instruction, not a label

A useful revision description can be read once, on a phone, on site, and acted on. It names the location, the old condition, the new condition, and any action the field must take — in that order. Compare the two versions of the same change:

None of those narratives is long. Each one does three jobs the cloud cannot: it states the change in words a trade lead can forward without the drawing, it records what the previous condition was so the field can spot work already done the old way, and it names the one follow-up action, if there is one. The changes that survive a pre-issue coordination review of drawings against specs still need to be just as legible when they reach the field as revisions.

A small standard that survives a fast ASI cycle

The fix is a pairing rule, enforced at issue, not a new form. Before any revised sheet leaves a small studio, check four things:

1. Every cloud has a delta, and every delta appears in the revision block. An unmatched cloud, or a delta with no block entry, is an unfinished issue — hold the sheet.
2. Every revision block entry is dated and written as a sentence, not a code. "ASI 07" is a filing reference, not a description. A concise version goes in the block, keyed by delta number to the fuller narrative in the ASI document, and the two are checked against each other at issue — that check is what keeps the sheet and the instruction from drifting apart.
3. The ASI lists every affected sheet and detail by number. Contractors work sheet by sheet. Listing sheets and details makes the package easier to route and check; one that says only "see attached revisions" leaves that sorting to the field. This is the same routing problem that makes drawing gaps turn into RFIs on remodel sets — the field cannot act on information it cannot find.
4. One person owns the revision log. On a 1–5 person studio that is usually whoever issued the ASI. The log is simply the running list of deltas, dates, and narratives, kept with the set — the same log that later makes record drawings compiled from the project's changes possible instead of painful.

Studios that issue revisions inside a revision freeze window can use the same discipline for batching: nonurgent changes can be held for the window and described once, instead of arriving as five unexplained clouds across five days — subject, always, to coordination needs and issue deadlines.

If producing clean, fully narrated revision packages is the part of production that keeps slipping in your own studio, that is exactly the kind of behind-the-scenes drawing support Creo's solutions for design teams are built to cover.

Keep the ASI inside what an ASI is

A clear narrative does not expand what an ASI can do. Under the AIA A201 framework, a minor change in the work — consistent with the intent of the contract documents, with no adjustment to the contract sum or contract time — is ordered by a written instruction, commonly the ASI form. Clarifications, small corrections, and added detail for already-approved design are its natural territory. Note, too, that issuing that instruction takes the appropriate contractual role: a boutique studio or production partner may prepare the revised drawings and draft the narrative without holding the authority to issue the ASI itself.

That boundary matters for the narrative itself. If the contractor reads your description and sees cost or time in it, that assertion does not settle the question by itself — it triggers review under the contract's change procedure. Calling a change "minor" in the narrative does not make it so. Changes that genuinely adjust sum or time belong in a construction change directive or a change order, resolved through that procedure. Contract language varies by project and agreement, so treat this as a working description of the standard framework, not advice on any specific contract.

Questions drafters ask

Does every small cloud really need its own description?

Every delta needs a description, but clouds that belong to the same change share one. If one ASI moves a door and swings its hardware, that is one narrative covering both clouds. The rule is one clear sentence-set per change, not one per outline drawn.

Where should the narrative live — on the sheet or in the ASI letter?

Both, and kept consistent. The revision block on the sheet — a concise description — is what the field sees first; the ASI document carries the fuller narrative and is the formal record. Key the two by the same delta number and check them against each other at issue: when block and letter tell different stories, the team ends up trusting whichever one they read and arguing about the other.

What if the change is purely graphical — a fixed typo or a moved note?

Say exactly that: "Note 4 moved to the left margin for legibility; wording unchanged, no change to scope, material, or layout." Naming that nothing physical changed is useful information — it tells the field they can stop looking for a construction change and file the sheet.

How long should a revision description be?

Long enough to state the location, the old condition, the new condition, and the required action — usually two to three sentences. If a change needs a paragraph, it probably needs a sketch or a revised detail as well, and the narrative should point to it by number.

Should we remove the cloud once the change is incorporated?

Usually, yes — follow your project's agreed revision protocol, which on most sets means clouds and deltas belong to the revision they announced and come off the next full issue, with issued versions and the revision block preserving the history. Leaving old clouds on a clean reissue trains the field to ignore clouds generally, which is the original problem returning in a new form. Where a submission rule or client standard says otherwise, that rule governs.

---

A cloud tells a busy contractor that something on the sheet is different. A delta tells them which issue it belongs to. The narrative — read with the revised drawing and details — tells them what actually changed and what to do about it. Pair all three, every time, and an ASI becomes far easier for the field to identify, interpret, and act on.