TRUE NORTH JOURNAL · FOR ACCOMMODATION OPERATORS
Keep accepted checks connected to current evidence
An earlier pass belongs to the conditions it tested. Use a small change register to decide what still holds, what needs clarification and what must be tested again.
- Identify the dependencyWhich accepted result relied on this rule, setting or source?
- Judge the material changeWould the difference alter the result or its permitted effects?
- Close with evidenceRecord the targeted test, owner decision and remaining limits.
Imagine you oversee a small hotel’s reservation and guest-communication systems. Your team checked that a room change reached the right destination. Later, an integration’s permissions or a supplier’s delivery rules change. You must decide whether the team can still rely on that earlier check, or whether a specific part needs to run again.
This guide is for the operator responsible for maintaining an already accepted workflow. It is less useful for an owner simply comparing management proposals or a team choosing software for the first time. Owners can ask who is accountable for reviewing changes; they should not need to troubleshoot their manager’s systems.
A software workflow can pass a careful check and later operate under different conditions. Repeating every historical test is wasteful. Keeping the old green result without checking its dependencies can be misleading.
The useful decision is narrower: which previously accepted assertion has become uncertain, and what evidence would make it reliable again? This guide provides a way to answer that question without turning every edited webpage into an incident.
Start with the result you actually accepted
“The integration works” is too broad to maintain. A useful acceptance record names the workflow, the required result, its important restrictions and the evidence from its last valid test. It also names the person responsible for deciding whether that evidence remains sufficient.
For an accommodation operator, one assertion might concern whether a room reassignment reaches the correct guest-facing destination. Another might concern whether an optional message stays suppressed after a consent withdrawal. These are examples of assertions to define and test, not claims about a particular platform’s capabilities.
Link each assertion to the sources and settings it relies on. Keep the supplier’s product, edition, interface and documented rule separate from your own configuration and observed result. A vendor guide is evidence of what the vendor says; your test records what happened within its stated scope.
Decide whether the change matters
Use the following table as an original triage aid. The responsible operator must set the actual release rules for the workflow and the risks it carries. A document’s changed date is a reason to inspect its operative wording, not automatic evidence that a system changed.
| Observed change | Question to resolve | Targeted evidence to seek |
|---|---|---|
| A supplier changes a delivery or retry rule | Did our accepted recovery assumption depend on that rule? | Current interface-specific wording, clarification if inconsistent, and a permitted test of the affected recovery path. |
| A plan, permission or consent setting changes | Is the previously permitted action still permitted and available? | Current entitlement or permission evidence and a test of the affected allowed and blocked actions. |
| A property, room or destination mapping changes | Can an old identifier route information or an action to the wrong place? | Approved current mapping and an isolated test of reassignment and stale information. |
| An application, model or knowledge source changes | Which outputs and restrictions relied on the previous version? | The changed version, its affected assertions and the relevant test cases, including previously difficult cases. |
| The handoff owner or escalation destination changes | Does the necessary work reach someone who can accept it? | A permitted handoff test and an actual receipt at the agreed destination; a queued request is insufficient. |
| Formatting, navigation or a footer date changes | Has any relied-on rule, meaning or dependency changed? | A recorded comparison. If the operative content is unchanged, explain why the existing evidence still applies. |
The table is deliberately about dependencies. A new icon may not affect a back-office export at all. It may matter greatly to a guest who can no longer find the action. Choose the test from the affected reader or operating outcome, rather than from how large the code change looks.
Keep documentation conflicts visible
Primary documentation can disagree. On October 19, 2026, HighLevel’s Marketplace retry support article contained incompatible descriptions of non-429 failures. Its Webhook Logs Dashboard documentation described another retry account. Those observations establish a documentation conflict, not a failure in anyone’s live operation.
If an accepted workflow depends on that behavior, record the exact interface and disputed assumption. Obtain a scope-specific clarification or conduct a separately authorized isolated test. Do not choose the most convenient paragraph, apply a Marketplace rule to an unrelated inbound workflow, or resend a real historical event simply to investigate.
A supplier’s change log can help identify what to inspect. The Mews Connector API change log identifies some availability-description revisions in its October 19, 2026 entry as documentation-only. That distinction can justify a different follow-up from a change in API behavior. The operator still checks which accepted assertion depends on the wording; the entry does not establish a particular account’s use or entitlement.
Choose one of four recorded outcomes
No material change
Explain why the relied-on meaning and conditions still match. Preserve the earlier test’s date and limits.
Clarification needed
Identify the conflicting or missing evidence, the owner and the next useful recovery trigger. Uncertainty is not a pass.
Retest required
Name the affected assertion, its expected outcome and the permitted test. Keep still-valid evidence for unrelated areas.
Acceptance suspended
Use the operator’s actual authority to hold the affected capability where its defined risk or release rule requires it. Record the fallback and restart evidence.
These labels are proposed editorial categories, not a vendor standard. “Suspended” should refer to a precise capability and condition, rather than imply that every part of the business has failed. A separate incident process still governs an actual incident.
Copy the change register into your approved private workspace
Use evidence references rather than copying guest conversations, credentials or sensitive configuration into a public document. Keep actual-output and retest-result fields blank until a run exists.
Assertion / workflow: Required result and restrictions: Accountable owner / decision authority: Relied-on source, interface and inspected date: Accepted configuration or source version: Last passing test / evidence reference / scope: Observed change / discovery time: Why it is material, immaterial or uncertain: Affected test and expected result: Permitted test environment and side effects: Decision: NO MATERIAL CHANGE / CLARIFY / RETEST / SUSPEND Actual retest evidence and limitations: Decision owner / decision time: Fallback or rollback, if applicable: Next review trigger / unresolved dependency:
Keep the earlier record intact and add the new decision. Replacing an old pass with a cleaner-looking current entry loses the information needed to understand what was proved before the change.
A worked example: a repaired report is still awaiting its release check
Imagine a report generator previously checked with short labels. A supported longer label reveals clipped output. The team prepares a correction and obtains a clear controlled test result for that candidate. The live service still uses the earlier renderer.
The register should distinguish the new candidate’s controlled evidence from the live service. The changed assertion concerns preservation of report content at the supported boundary. The targeted check is the relevant output, with its source version and original values, after the authorized release. A successful local test cannot establish that the live renderer changed.
This is an illustrative scenario, not a published account of a True North customer incident. It shows why “fix prepared,” “release authorized,” “deployed” and “affected output verified” are separate states. If a release is blocked, record the real dependency and its owner; do not rerun unrelated checks to create the appearance of completion.
Close the changed assertion, not just the task
After an authorized correction, compare the actual result with the expected one. Record the version, test conditions, relevant output and the decision made by the person responsible. If another team must accept a handoff, retain its actual response. If the result remains unavailable, the assertion remains unresolved.
For workflows using generative AI, NIST’s Generative AI Profile supports maintaining evaluation history, reviewing source evidence and revisiting safety assumptions in changed circumstances. The worksheet here is our practical adaptation; it is not a NIST certification or a universal retest threshold.
The guest-messaging AI test pack provides a separate starting set of fictional cases. Use the change register to identify which accepted cases must reopen; do not treat the existence of that pack as an executed test.
Review whether the method is useful
If the operator separately adopts this method, a seven-day review can ask whether critical assertions have named owners and inspectable versions. At twenty-eight days, examine unresolved material changes and their ages, excluding cosmetic edits. At fifty-six days, review changes that escaped the agreed review and whether the closure evidence was sufficient.
These are suggested learning windows. Count the actual reviewed population, retain unknowns and distinguish newly found changes from repeated observations of the same issue. Neither a completed worksheet nor a before/after difference proves improved revenue, fewer incidents or greater owner retention. The practical goal is to keep a relied-on decision connected to evidence that still applies.
When discussing hotel and multi-unit management, owners can ask which responsibilities their proposal covers, who owns material changes and what evidence supports a restart. The property-specific agreement defines the actual service.
