Version Stamp Convention

Every reference page in this space should declare which version of OpenELIS Global it has been verified against. Here's how.

Why

OpenELIS Global ships continuously. A page that's accurate for v3.0 may not match v3.2 — and a reader who can't tell which version a page reflects has to verify everything against the live system anyway, which defeats the purpose of documentation. The version stamp answers two questions at a glance: What version does this describe? and How recent is that verification?

The stamp

Place this line at the bottom of the page, after the main content, in italics:

Last verified against OpenELIS Global v3.2.1.3 — 2026-05-21 (by Casey Iiams-Hauser)

Three parts:

The OpenELIS version in dotted form (v3.2.1.3 not "version 3.2.1.3" or "3.2"). The third digit tells the reader the stability tier (alpha / beta / production-ready) and the fourth is the patch level.
The date of verification in ISO format (YYYY-MM-DD) so it sorts and parses unambiguously across locales.
The verifier (optional but encouraged). If unsure of the verifier, omit rather than guess.

When to update the stamp

You verified the page against the live system today → update to today's date.
You edited the page but didn't open the live system to verify → leave the stamp alone. Editing without verifying doesn't refresh it.
You added a new section that needs verification → mark just that section with an inline DRAFT note.

Granularity

One stamp per page

Most pages get one stamp at the bottom. The whole page is the unit.

Inline section stamps when sections diverge

If a page is mostly current but one section is known to be out of date, add an inline panel above that section:

This section needs verification against v3.2.1.3. It was written for an earlier version and may not reflect the current UI.

Source HTML:

<div data-type="panel-warning">
<p><strong>This section needs verification against v3.2.1.3.</strong> It was written for an earlier version and may not reflect the current UI.</p>
</div>

Verification workflow

Open the page you're verifying.
Open the live OpenELIS Global instance.
Walk through every claim on the page — field names, button labels, menu paths, screenshots, workflow steps.
Edit anything that doesn't match.
Update the version stamp at the bottom with today's date and your name.
Save with a clear version message: "Verified against v3.2.1.3 — YYYY-MM-DD".

When the version changes

When OpenELIS ships a new version, the previous stamp doesn't automatically become wrong. A page verified against v3.1 may still be 100% accurate in v3.2 if nothing in that area changed. Treat the stamp as "last known good", not "currently broken". The verification cadence is: walk the pages relevant to a release after that release ships, and re-stamp the ones that still hold.

What gets stamped

End User Manual + Quick Reference pages — verified per release
Administrator Manual + Quick Reference pages — verified per release
Module & Feature pages — verified per release
Implementation guides — verified at the start of each new implementation
Troubleshooting — verified when an entry is added or updated
FHIR Implementation Guide — verified per FHIR profile release

What does NOT get stamped

Meeting notes (point-in-time records)
The workplan and other meta documents
Roadmap pages (forward-looking, not reference)
Community pages (people and processes, not product features)

Tracking unverified pages

Pages still on a DRAFT prefix or without a stamp are tracked under the New User Manual sections to be verified parent. The plan is to verify them in batches and remove the DRAFT prefix as they're confirmed against the live system. See the revamp workplan for the broader Phase 3 timeline.

📌 Version Stamp Convention