Never a fake green: how ENTRIX watches itself

A check-in platform fails in quiet ways. A background job runs on schedule and does nothing. A vendor changes an API response. A step of the guest flow breaks at 2 a.m. and nobody tries it until a guest does. ENTRIX has two systems for finding those failures before a guest does: App Health, a board inside the staff dashboard, and a synthetic monitor that walks the guest flow on its own.

App Health covers more than forty modules, from reservation lookup, document scan and face comparison to door codes, TM30, tablets, email, LINE notifications and scheduled jobs. Each module declares typed checks, and there are four types. Configuration checks confirm that required settings are present, reporting only the names of variables and never their values. Probes make a live, time-bounded call against the real dependency, cached so the board can refresh without hammering vendors. Activity checks measure what real traffic experienced: last success, failure rate, backlog. Self-tests run pure logic, such as name matching, against fixtures in process.

The roll-up has one rule that matters more than the others. Red means a required check failed. Amber means degraded, stale, no traffic or indeterminate. And a check that has not been built reports amber, not green. It is tempting to leave an unimplemented check out, or to default it to passing so the board looks finished. Both make the board lie. The same honesty applies to scope: the TM30 module reports that ENTRIX prepares and tracks the immigration record while staff make the submission, so an operator never reads a green tile as meaning filing is automated.

Scheduled work gets the same treatment. ENTRIX runs eleven scheduled jobs, including an hourly door-code reconcile, reservation sync and the synthetic monitor itself. A job that reports it was skipped is not a job that completed, and the board counts them differently. A cron log that says the job ran every ten minutes proves the scheduler works, not the job.

The synthetic monitor goes a step further and drives the application's real code paths. Fourteen scenarios cover the guest journey: reservation lookup, name matching, document scan, the liveness pre-flight, face comparison, TM30 generation and top-up, a door-code dry run, QR generation, outbound email, early-arrival and late-departure links, face-entry gates, the in-stay guest portal token and check-out. A scenario that cannot run says why, rather than passing.

Running a monitor against production identity software raises an obvious question: what does it verify? Never a real person. The image-driven scenarios run on committed specimen fixtures: faces that are flat vector drawings, and a test card from a fictional authority with a fake number and a fictional nationality, with a holder line stating it is not a person. The rule that neither may ever be replaced with a real face or a real travel document is written next to the files. Where a scenario exercises ENTRIX's own decision logic, the AI vendor is stubbed and the result says so, and vendor reachability is covered by a separate live probe.

Isolation is enforced at the boundary, not left to convention. Synthetic sessions are marked as such, excluded from every metric the board reports, and blocked from the lock provider, the PMS and guest email. Every five-minute tick ends with an audit and sweep that runs even when the tick failed, because the rows most in need of cleaning up are the ones a failed run left behind. The monitor observes and reports; it does not gate deployments.

None of this is novel engineering. It is probes, fixtures and honest status codes, applied with the same seriousness as the verification itself. The standard is simple: when the board says green, a person can believe it.