Guides
Part of How to plan industrial site interpretation: a workflow for visitor teams
How to keep industrial site interpretation planning records ready for a new owner
Planning records for industrial visitor programs hold the charter, source log, route version, media rights and review dates in one findable place.
A visitor program outlives the people who built it. The guide who knew why Stop 4 was reworded leaves, the panel file moves, and the next editor inherits a route with no reason attached to it. A planning record is what stops that.
What to take away
- One record per visitor item, holding the live text, its source, its approval and its next review date.
- A project charter sets purpose, scope, audience and exclusions before anyone writes panel copy.
- Route records carry the current sequence and the site version they were checked against.
- Media records name the file, the credit, the rights holder and where the item appears.
- A change log explains why the current version differs from the one it replaced.
The records a visitor program needs
| Record | Minimum content |
|---|---|
| Project charter | Purpose, scope, audience, exclusions |
| Source log | Claim, source, date, permission, reviewer |
| Route record | Current sequence, site version, access notes |
| Media record | File, credit, rights, alt text, location |
| Approval note | Reviewer, date, approved wording, limits |
| Change log | Change, reason, decision, affected items |
Stable filenames and version dates do more work than any folder structure. A folder called "final" stops meaning anything the second time someone creates one. A version number and a date tell the next editor which file is live.
Index Fields to Keep
- Current public item name
- Where it appears
- Who owns it
- Date last checked
- Whether a review is pending
Keep a short index alongside the records. It names the current public item, where it appears, who owns it, the date it was last checked, and whether a review is pending. Without it, a retired draft gets mistaken for the version a visitor is reading.
The planning records system behind a tour program is smaller than an archive and larger than a shared drive. NARA's metadata requirements resource gathers the federal guidance on describing permanent electronic records. A heritage site does not need that apparatus, but the principle transfers: a record nobody can identify is a record nobody can use.
When a source, route or approval changes
A corrected source, an expired approval or a rerouted walkway each break something already published. Find every item that depends on the changed fact, then revise, replace or withdraw it. Write down the reason, because the next owner will need to know why the current wording differs from the earlier one.
The NPS planning policy runs a record from purpose through to action. A site can borrow that shape: visitor goal, scope boundary, source baseline, then the route version and approvals that follow. Meeting notes stay out of the visitor material. What survives is the reason a public item exists and the evidence behind it.
For public pages, the National Archives web-records guidance covers preserving changes over time. A working record can be plain: the live copy, the previous version, the date, the reason and the approving authority. When a route changes, that history is what tells you which panels, maps and guide scripts were checked afterwards.
Theme is the other half. The NPS National Historic Landmarks thematic framework shows how a resource is tied to a national theme.
Record the source supporting the theme, the anchor a visitor can see, the published wording and any limit on the claim.
A topic discussed once in a planning meeting is not evidence, and a broad theme is not a licence to assert it.
Handing the records to a new owner
Give every visitor item a stable identifier. A route-stop code, a panel number, a page slug or a guide edition all work. Under that identifier sit the live text, the source notes, the media credit, the approval and the change log.
A new editor should reach the live item and its evidence without opening unrelated folders. That is the whole test of the system.
When an item is deferred or retired, keep the reason and the version it was retired from. Say whether another item covers the visitor need, whether a contact path replaces it, or whether nothing does. Private contacts and controlled operational detail stay in the systems authorized to hold them, never in the visitor-facing record.
Review the index at every material change. Confirm it points to the current page, map, panel file or script, and that a named person owns the next check. The index does not need every detail. It needs to make the live material findable.
Common questions
Is a spreadsheet enough for planning records?
It can be, provided it links to the source files, approvals, live text, media records and the named owner. The links matter more than the tool. A spreadsheet nobody maintains is worse than a folder with clear filenames.
Should working comments be published?
No. Review comments, contact details and draft disagreements belong in the working record. Publish only approved visitor material and the credits that go with it.
Who updates the change log?
The assigned content owner records approved changes and confirms the related public items were checked. One name per item, not a team. An unowned log stops being written within a month.
What happens to a record when a tour is discontinued?
Keep the decision reason and the final version. Note whether another stop, a contact route or nothing at all covers the visitor need. That note is what keeps the retired file from reappearing as current content.
