A Tampa plan-review correction should preserve the original issue, the written response, the corrected sheet, and the City’s next disposition. Do not overwrite the first drawing and call the newest PDF the whole record.
Also keep three labels separate: an issue is not a condition, and neither is automatically a later field revision.
Use Tampa’s terms before assigning the next task
The City’s current digital-plan FAQ supplies the controlling distinction:
| City record | What the City says it represents | Evidence to preserve |
|---|---|---|
| Issue | A code-related concern that must be corrected on the appropriate drawing | Issue ID/text, cited sheet, written response, corrected sheet, new disposition |
| Condition | A concern that can be corrected in the field by inspection staff | Condition text, responsible party, approved drawing reference, field/inspection result |
| Corrected-sheet upload | The post-cycle response to review issues | Only changed sheets, acceptable digital signatures, response set, upload receipt |
| Field revision | A separate route for a change associated with approved work | Approved baseline, proposed change, field-revision submission, decision, revised field set |
The label determines the evidence path. Do not redraw a condition unless the City asks for drawing changes. Do not tell an inspector that an unanswered issue will be handled in the field.
If the Plan Room is missing, the FAQ says the user must be a contact on the record; the primary contact adds that person. Upload processing can also continue after navigation away from the page, with an email when processing finishes. That email is not the notification that a review cycle has finished.
Build one row for every review issue
Use this nine-field ledger rather than a folder of files named “final”:
| Field | Entry |
|---|---|
| Permit record | City record number and address |
| Review cycle | Cycle number and completion notice date |
| Issue | Exact City issue identifier and text |
| Baseline sheet | Original sheet number, title, revision/date, and filename |
| Response | Written answer, responsible design party, and response date |
| Corrected sheet | Same sheet identifier, new revision/date, and change summary |
| Signature check | Signer, certificate-validation result, and unresolved error |
| Upload | Package name, date/time, receipt, and uploader |
| Disposition | Cleared, returned, changed, or still open—as the City records it |
The FAQ says revised-plan submissions need a written response to each issue and only the corrected sheets. It also says those sheets still require third-party-verified digital signatures. That makes the response set and signature state part of the correction evidence, not administrative extras.
Tampa’s dated issue-response guide remains linked from the current tutorial hub. Follow the live City route, and save the task result with the permit record instead of relying on browser history.
Wait for the cycle boundary
The FAQ says applicants may not upload new plans mid-cycle. The review cycle must finish before new plans can be uploaded.
That boundary should appear in the ledger:
- save the submitted-cycle package;
- wait for the City’s cycle-complete notification;
- export or save the complete issue list;
- assign each issue to a response and sheet;
- validate the corrected files and signatures;
- upload the correction package; and
- preserve the receipt and next-cycle result.
The City’s tutorial index lists viewing issues and conditions, saving the issue list, responding to issues, responding to conditions, and uploading corrected sheets as separate tasks. Mirror that separation in the project folder.
Keep the baseline sheet immutable
For each corrected sheet, retain:
- the originally submitted file;
- the City-marked or issue-linked baseline;
- the revised sheet with its own revision/date;
- a short response that identifies the change location; and
- the City’s accepted or returned result.
Do not rename all versions to the same filename outside the portal. A sheet-number match without a revision/date match can send the field team back to an obsolete detail.
Conditions need their own log. Record the field action, responsible trade, planned inspection point, and the inspection evidence that actually resolves it. A condition description is not itself proof that the field work passed.
Open a new branch for a field revision
A field revision is not available for every change to approved plans. The linked guide limits this route to minor deviations, with eligibility determined and approved by a City construction inspector. Start with that authorization and the approved sheet as the baseline. Tampa’s field-revision landing says posted August 4, 2026, but its four-page download is internally dated November 21, 2023. The actual field-revision instructions require an author-signed narrative and a one-page detailed plan signed by the contractor, also by the engineer if structural. Enter the parent permit and verify its populated address; the resulting payment receipt and FR record number are not final technical approval. Preserve the field-revision record number or submission, affected sheets, reason, approval status, and distributed approved revision.
Do not insert a changed field sheet into the old plan-review correction folder and erase the approved baseline. The point is to show what the City approved first, what later changed, and which version reached the inspector and contractor.
Source and method
Local Service Ledger rechecked the four City pages and read the complete two-page issue-response and four-page field-revision downloads on September 21, 2026. The issue guide asks for a descriptive response explaining corrective measures, not just a changed drawing. We organized them into a nine-event cycle ledger. We did not access an applicant account, examine a permit, validate a signature, or decide a review outcome.