Skip to content
Support
  • There are no suggestions because the search field is empty.

How Do Approval Flows and Versioning Work?

This article explains Hapax’s versioning model (Edit → Live → Past), how approvals work from start to finish, and how approvals affect what gets retrieved/cited in answers. 

1) Versioning Model — Definitions (plain English)

  • Edit — The working copy. Editors make changes here. It may show Change Impacts to related documents while you work toward a clean submission.

  • Live — The approved, current source of truth. This is the version that downstream users read and that the Assistant uses for retrieval and citations.

  • Past — Read-only history snapshots that preserve prior Live versions for audit and reference.

Why this model works: Hapax’s standardized, part-level representation and cross-document links make it clear what changed and what else is affected, so approvers can promote clean, coherent guidance to Live with confidence.

2) Approval Flows — Single-Step and Multi-Step 

We use generic roles here (saving deep permission mechanics for a separate article): Viewer, Editor, Approver, Admin.

  • Single-step: Editor → Approver → Live
     Use when scope is narrow (e.g., a minor clarifying change). Notifications go to the document owner, listed approver(s), and any watchers; outcomes surface in the Notification Center.

  • Multi-step: Editor → Compliance review → Final Approver → Live
     Use when changes impact regulated content or multiple downstream procedures. Each step notifies the next reviewer and records the decision; outcomes surface in the Notification Center.

3) Best-Practice Gate Before Submit (light model)

  • Resolve Change Impacts first. Edits can produce impacts on related documents. Best practice is to resolve all impacts before submission so the approver isn’t reviewing changes that would still ripple elsewhere.

  • Attach citations or references needed for approvers to verify key assertions (policy sections, effective dates).

  • Summarize what changed and why, in 2–3 bullets, to speed approval.

Why impacts exist: Hapax maps relationships between document parts so it can flag inconsistencies early (e.g., when a policy change requires a procedure update).

4) What Triggers an Approval (high level)

Approvals are typically required when:

  • Promoting a new document to Live.

  • Material content changes to an existing document (policy/procedure text).

  • Critical metadata changes that affect interpretation (e.g., effective dates).

Notifications are sent to the owner, listed approvers, and watchers/subscribers; the Notification Center shows current status and outcomes.

5) End-to-End Flow (narrative)

  1. Open the Edit version. The Editor reviews the draft updates and checks for Change Impacts to related documents.

  2. Resolve impacts. Make coordinated updates so related procedures/guides remain consistent.

  3. Submit for approval. A single-step or multi-step flow routes the change to the right reviewers; notifications are sent.

  4. Approval → Live. When approved, the Edit version is promoted to Live; prior Live moves to Past. The Notification Center reflects the outcome.

  5. Answers now cite the new Live. The Assistant uses Live only, so answers and citations reflect the updated content.

6) ASCII Table — States at a Glance

State

Who sees it

What you can do

Typical actions

Edit

Editors, Approvers

Update content; view Change Impacts; add citations/notes; Submit for Approval

Finish edits, resolve impacts, submit for approval

Live

Everyone (viewers by default)

Read, cite, and use in answers; no direct editing

Serve as source of truth; drive retrieval/citations

Past

Everyone (based on permissions)

Review historical text; compare with Live; cannot edit

Audit/reference, learn from history

7) Short Demo Script (2–3 minutes)

Scenario: Updating the Overdraft Policy to align with a revised fee schedule.

  1. “We’re in the Edit version of the Overdraft Policy. I’ve made a small wording change and I see Change Impacts to the Teller Guide.”

  2. “I open the impacted guide, align the steps, and return. Now there are no outstanding impacts on this policy.”

  3. “I Submit for Approval. The approver is notified, reviews my summary of changes, and approves.”

  4. “The policy is now Live. In the Notification Center, we can see the approval outcome.”

  5. “If I ask the Assistant to summarize overdraft rules, the answer cites the new Live version automatically.”

8) FAQ (concise)

Q1: What’s the difference between Edit, Live, and Past?
 Edit is the working copy; Live is approved and authoritative; Past is read-only history.

Q2: Do I have to resolve Change Impacts before submitting?
 Best practice: yes. It reduces back-and-forth and ensures approvers promote consistent guidance.

Q3: Who gets notified during approvals?
 The document owner, listed approvers, and watchers/subscribers. Outcomes surface in the Notification Center.

Q4: When is approval required?
 New documents going Live, material content changes, and critical metadata changes (e.g., effective dates).

Q5: Why didn’t my change appear in answers yet?
 Because only Live is used in retrieval. Submit and obtain approval so the Edit becomes Live.

Q6: Can viewers see works-in-progress?
 No. Viewers see Live only; Edit is restricted to editors/approvers. Past is read-only history.