Imagine that a product's battery range changes on Monday. The website is updated, but an experience centre still shows the old figure on a touch table, a wall display and a take-home QR page. Replacing one text string in a CMS is only part of the job. The venue needs to know which source is authoritative, where the fact appears, who approves the change and how to verify the public journey afterward.
An experience-centre handover guide from IDA GCC calls for content/version ownership and paired language updates. Power Interactive's FAQ describes client-managed content changes for permanent installations. These are suppliers' operational recommendations, not measured proof that a particular CMS will make changes effortless. The practical gap is a repeatable correction, especially when a fact appears in more than one medium.
Begin with a fact, not a screen
Record the changed claim as a unit: product ID, old value, approved new value, unit, source document, source owner and effective date. List each consumer of that value: kiosk result, comparison table, Arabic narration, wall graphic, downloadable sheet, website destination and staff script. If one claim is embedded in a video, it may need a different remedy from text stored in a database. A visible “temporarily unavailable” state may be more truthful than leaving an obsolete value while a replacement is made.
The AVIXA public description of its AV documentation standard says the framework covers documentation requirements, who creates them and how delivery is tracked. It is a useful basis for assigning records and owners. It does not certify that a venue's product data is accurate, and the full paid standard was not needed for this workflow.
An illustrative correction record
The following is an invented operational example, not a real product specification or Archv project result.
| Item | Example record |
|---|---|
| Change | Product P-12 range label changes from a placeholder “A” to approved value “B”; no numerical range is published in this example. |
| Source | Product owner's approved specification, revision 7, dated and linked in the internal content register. |
| Affected touchpoints | English and Arabic product card, comparison result, staff tablet, QR page and one narrated segment. |
| Approval | Product owner verifies the fact; Arabic reviewer verifies meaning and units; venue editor approves the release set. |
| Release | Publish one version ID for both languages; keep previous approved package available for rollback. |
| Verification | Open the station as a new visitor, select P-12, compare it, switch language, follow QR link and confirm every displayed claim matches revision 7. |
| If a touchpoint is late | Mark that content unavailable or hold the release; record the exception and responsible owner. |
The record should use real values, file references and names in production. The example avoids inventing a universal approval hierarchy: the right owner depends on the buyer's organization and the product's risk.
Release both languages as one visitor promise
An English update and Arabic update that publish on different days can produce contradictory comparisons. The content register should identify both versions as one approved set. Test a mid-journey language switch, text direction, units, embedded media and any printed or QR-linked follow-up. A translation reviewer needs the source fact and context, not only an isolated string. If the two languages cannot be ready together, agree an honest temporary state rather than silently publishing different claims.
This is separate from the site's general guide to staff website editing after launch: an installed experience has physical displays, offline packages, operator devices and a visitor route that may join several systems.
Keep a rollback and prove the actual display changed
Preview in a staging environment, then record the published package ID and time. Test at the actual display or media player, because an editor preview can be correct while a local player holds an older cached package. Capture the result of the comparison, language switch and QR destination. If any path still carries the old fact, roll back the package or take that path out of use, then assign a fix. The plan should say who can perform each action during opening hours.
After release, update the content register and the operator note. A future editor should be able to answer: What changed, why, where, who approved it, what was tested and which version is running? That is the useful meaning of content ownership after handover.