ENTRIX runs across seven hotel properties in one portfolio. They share a brand standard, a technology stack and a compliance obligation. They do not share a lobby, a guest mix or a front-desk team. A verification rule that is right for one of them can be too strict, or not strict enough, for the property down the road.
Until August, changing that rule meant changing code. Since 11 August it does not. Every verification check in ENTRIX is configurable per property from the dashboard, without a deploy.
Every check is a setting
A verification flow is a sequence of decisions: is the document readable, is the person live, does the selfie match the portrait, does the name match the booking. For each of those, a property decides whether the check runs, whether it blocks, and how strict it is.
In many systems those values live in source code or in an environment file. Changing one means an engineer, a release and a deployment window, which is why they rarely change, and why the values chosen at launch tend to outlive the conditions they were chosen for.
In ENTRIX they live in policy. Operations staff with the right access change them from the same dashboard they use for verifications, failed scans and the immigration registration worklist. The next guest is verified under the new setting.
Off, advisory or strict
Each check has three states.
- Off. The check does not run.
- Advisory. The check runs and its result is recorded, but it does not stop the guest.
- Strict. The check runs and a failure stops the flow, sending the guest to staff.
Three states rather than two is the important design choice. A switch between off and on forces a property to decide on a control before it has any evidence of how that control will behave with its own guests. Advisory mode removes that guess.
Measure before you enforce
Advisory mode exists so a property can measure before it enforces. A new check, or a stricter setting on an existing one, can run alongside live traffic and record what it would have done. The operator then looks at real outcomes at their own property: how many genuine guests the check would have stopped, and which ones.
Only then does the check move to strict, and the decision to move it rests on that property's evidence rather than on a vendor's default. If the result is not acceptable, the check stays advisory, or the setting changes, and nothing has been deployed in either case.
Portfolio defaults, property overrides
Seven properties each choosing every value from scratch would be its own kind of risk. Settings therefore inherit from portfolio defaults, and each property can override them. A property that has set nothing follows the portfolio's policy.
That gives the organisation a clear place to act. The portfolio sets a floor. A single property overrides only what is different about it, and everything it has not overridden keeps tracking the defaults.
When a check cannot run
Policy changes how strict a check is. It does not change how the system behaves when a check cannot run at all. If verification is unavailable, ENTRIX fails closed to staff review, whatever the setting.
What this means for each reader
For an operator, verification becomes something the property manages rather than something it waits for. A property can tighten a control during a period of elevated risk, or relax a check that is stopping genuine guests, the same day.
For a technology lead, the benefit is that policy and code have separate lifecycles. Releases carry changes to behaviour; policy carries changes to judgement. Code changes still go through review and testing before release. No property's setting requires a new build.
For both, the change is that a verification rule now has an owner at the property, and evidence behind it before it is enforced. More on ENTRIX is at opsiantechnologies.com.
