Engineers compare notes against a shared update log

How to Update Technical Infrastructure Articles Without Losing the Evidence Trail

A new site investigation can narrow the conditions under which a bridge-foundation example applies. The original article may contain no factual error, yet still mislead if it presents that example as general guidance. A date stamp will not resolve the problem. The publication needs a record of what changed, a check of the affected claims and a traceable correction.

For a transport-infrastructure publication, that means keeping an intake record, setting a priority, assigning an editor, obtaining a technical check where needed and recording what was published. Minor edits need not pass through formal review. Consequential changes, though, should not disappear into email threads or go live without evidence.

Keep one queue for proposed changes

Readers, engineers, editors and website maintainers spot different problems. An engineer may notice an overgeneralized statement about embankment settlement; an editor may find a missing source date; a site maintainer may discover that a diagram no longer displays. Put the reports in one queue, even if the fixes follow different routes.

A spreadsheet or issue tracker is enough if each entry captures:

  • The page title and its exact URL or content identifier.
  • The location of the affected passage, figure, table or file.
  • What appears wrong or outdated, and who reported it.
  • The supporting document or observation, with its date and scope.
  • An owner, priority, current status and next action.

Keep the reported issue separate from the proposed fix. “The paragraph does not distinguish measured movement from predicted movement” identifies a problem. “Delete the paragraph” is one possible response, but a narrower statement might be accurate. Record who raised the issue without treating that person's interpretation as verified evidence.

Engineers compare notes against a shared update log

Prioritize by consequence, not just age

An old page is not automatically unsafe, and a new one can contain a serious error. For each report, consider what a reader could reasonably do with the information, how certain the problem is and how widely the claim appears. A broken caption on a decorative photograph is not the same as a mislabeled ground profile used to explain foundation behavior.

Give urgent issues a containment route

If a page appears to give an unsupported design recommendation, misstate a material property or confuse an observation with a prediction, limit exposure while the claim is checked. The editor might temporarily remove the claim, qualify it clearly or take the page out of public view, depending on the problem. Record what changed and why. This temporary step does not replace technical review; it keeps an uncertain claim from standing unqualified in the meantime.

Bundle routine maintenance

Lower-consequence work, such as repairing internal navigation, improving a heading or replacing an inaccessible figure description, can be scheduled together. Periodic checks can also flag pages whose cited project stage, inspection date or dataset has changed. A post on preliminary tunnel investigation results, for example, should not present those results as final ground conditions. If later evidence is unavailable, state the stage and date rather than inventing an update.

Define roles at the handoff

The person who logs an issue need not be qualified to resolve it. Assign an editor to coordinate the update, then identify who should check the technical claim. A geotechnical specialist may be needed for a change about subgrade response; a structural specialist may be better placed to assess a bridge-load explanation. Choose the reviewer by the claim, not simply by the page category.

Decision authority should be clear. An editor can fix grammar or formatting without engineering approval for every keystroke. Changes to assumptions, units, limitations, causal explanations or interpretations of monitoring data need a competent technical reviewer. If that review is unavailable, narrow or remove the claim rather than publish an unverified replacement as settled fact. An article update is not project-specific engineering approval.

A useful status sequence is reported → triaged → assigned → checked → published → closed. Add “waiting for evidence” when necessary, along with a named next action. A comment alone does not close an issue. Closure means the public material has been checked, or the report has been dismissed with a documented reason.

Edit the smallest defensible unit

Before rewriting, find the claim everywhere it appears: headline, summary, body, figure caption, table, downloadable file and related excerpts. Correcting one sentence may leave a contradictory diagram behind. A broad rewrite, on the other hand, can introduce unrelated claims and create more work for reviewers.

Distinguish among three kinds of change:

  1. Correction: The statement was inaccurate when published. Replace it and retain the previous wording in the record.
  2. Update: The statement reflected the evidence available at the time, but later information changes what readers need to know. Preserve that time context.
  3. Clarification: The claim remains supportable, but its assumptions or limits need to be clearer.

For infrastructure topics, the distinction is consequential. New monitoring measurements do not necessarily make an older interpretation erroneous; a dated note may be enough to show which observations it used. A wrong unit in a table is different. Correct it, then check the calculations and prose that depend on it before undertaking a general refresh.

Figure labels receive a check against inspection records

Check evidence and presentation together

Give the technical reviewer the proposed wording, the previous wording, the supporting material and a specific question. “Does the revised sentence limit this finding to the monitored section and observation period?” is easier to answer than “Please review the page.” Ask the reviewer to identify uncertainties and conditions under which the statement would not hold.

The editor must then check that the approved meaning survives publication. Inspect units, labels, accessible descriptions, dates and quoted passages. A revised figure and the body text may each look plausible while referring to different monitoring periods. Keep the original evidence trail in the working record for interpretive changes so a later editor can see why the wording changed.

Check relevant internal links, too. If a paragraph sends readers to another page for a specific technical concept, confirm that the destination still covers it and that the link text is accurate. The separate discussion of internal linking for transport-infrastructure publications is relevant when an update changes how readers move between related explanations. Link maintenance should not broaden a narrowly scoped technical correction.

Leave a usable record after publication

Log the publication date, the editor, the reviewer where applicable, the evidence checked and a short account of the change. Add a dated note to the public page when an alteration materially changes its interpretation; minor copyedits usually need no such note. A bare “updated” label can imply a full technical recheck when only formatting changed.

Before closing the queue entry, open the live page rather than relying on approval in the editing system. Check the changed passage, figure, caption and any linked download. If an inspection article's table now gives displacement in millimetres rather than centimetres, read every sentence interpreting that table on the published page.