Platform
State of the platform: what AEGIS does today, and what it does not
A plain account of the AEGIS comp authority engine: what runs in production today, what is built with limits, what is not built, and what we have and have not measured. We would rather you read the gaps here than find them in a pilot.
As of 13 October 2026
How to read this page
Each line has one of three statuses. Running means it works on our two production sites today. Built, with limits means it exists but is incomplete, or has not been switched on. Not built means exactly that. Where a line has a limit, we say what it is next to the claim, not below it.
AEGIS is a decision and record system for comps and their authority. It is not a regulatory filer, a casino management system, or a certified product, and nothing here is legal advice.
What runs today
| Capability | Where it stands | What that means, and the limit |
|---|---|---|
| Authority decisions | Running | Every comp request is decided against the written authority matrix: approved, refused, or sent to the right person, with a second approver where the rules require one. Measured on the server, on one CPU, on 12 October 2026: about 10 ms at the median and about 35 ms at the 95th percentile. |
| Changing the rules | Running | A change to the authority matrix needs a second person with the right to publish. It can be simulated first, and back-tested against the decisions already made. A past decision can be re-run exactly for decisions made since 12 October 2026; earlier ones are reconstructed and labelled as such. |
| The audit record | Running | Every event is chained, anchored in a second store, signed with a key held outside the database, and, at least hourly, time-stamped by two public authorities. Limits: the signing key sits on our servers, not in a hardware module, and events newer than the latest outside timestamp (up to an hour) are not yet covered by it. |
| The regulator portal | Running | Read-only. The operator decides what each regulator can see (event types, dates, comp categories, masked fields, export rights), enforced in the queries and recorded when changed. Limits: the integrity check always covers the whole record, masking hides values and does not erase them, and the portal is not yet a separately hardened service. |
| Responsible-gaming gate | Running | A gambling inducement is held back from a patron whose recorded play shows harm, and a patron's own loss limit is honoured, under six licence configurations. Automated tests run every configuration through every path that offers value to induce play: a direct request, a campaign, an enrolment promotion, and an uncarded player who is losing heavily. Limit: the thresholds are illustrative defaults to be set with each operator's compliance team. This is not legal advice. |
| Offers and campaigns | Running | Bulk offers to targeted segments, each one a real comp decided through the same rules. An optional expiry date lapses what is unredeemed, and books it as breakage. |
| Finance foundations | Running | Gaming-day and period close with sealed snapshots, balanced journal entries, reconciliation and completeness checks, accruals as of a date, and a general-ledger export. Limit: no operator has run a real close on real data yet. The first one is refused until ledger setup is complete, by design. |
| Two sites, one writer | Running | Two sites in different countries, one writing and one following, with automatic failover. Planned switchovers have been run on production with no data lost and disruption from under a minute to a few minutes. |
| Comps with no connection | Running, off until enabled | A phone with no signal can grant a comp from a small, expiring allowance issued beforehand, limited by what the person's own authority covers. Every such grant is reviewed by a person afterwards, and anything beyond the allowance is flagged. Gambling inducements can never be granted this way. |
| Signing in | Running | Each login has its own password and a list of the identities it may act as; tokens are signed and short-lived. Limits: no second factor yet, and no sign-in through a customer's own identity provider. |
Built, with limits
| Capability | Where it stands | What that means, and the limit |
|---|---|---|
| Notifications | Built, not switched on | Alerts by email, a signed webhook and push to phones are built. None is switched on in our own production yet. |
| Backups | Built, not installed | Backup and restore tooling is built and tested. Automatic off-site backups are not running yet because no storage has been set up. Until then we take a verified copy before every change. |
| Connections to casino systems | Partly built | A generic redemption intake and an HR event and import interface exist. There are no vendor-specific connectors yet (casino management system, point of sale, property management, HR), and they need a pilot partner. |
| Compliance reporting | Built as a feeder | Sealed, versioned feeds for currency, suspicious-activity, gaming-win and cash-log reporting. AEGIS feeds a filing platform; it does not file with regulators. Thresholds are configuration, and counsel has not yet verified them. |
| Jurisdiction rules | Illustrative | Six jurisdiction packs exist. They are illustrative, hardcoded, and not reviewed by counsel. |
| Investigations | Partly built | Cases with assignment, escalation and a timeline, and two scheduled detectors (comps split to avoid approval, and comps to a declared related party). The scheduled detector uses fixed thresholds, and there are no evidence vaults or service-level clocks. |
| Reports on a schedule | Built, nothing scheduled | Any report downloads as a spreadsheet, and a report can be issued each time a gaming day closes. No one has scheduled one yet. |
Gaps
- Screening against sanctions and watch lists.
- Sign-in through a customer's identity provider, a second factor, and automatic user provisioning.
- An audit anchor on a separate host from the main database (the independent timestamps cover part of this need).
- An inbound feed from a casino management system, and a connection to a real exclusion registry.
- A SOC 2 or ISO 27001 programme and an independent penetration test.
- A written policy for patron personal data: what is stored and how long. The platform holds patron display names and tax flags today.
- Depth for hosts and marketing: trip records, contact logs, a points ledger with expiry, requalification, and measurement of what an offer achieved.
- Junkets, rolling-chip programmes, marker collection, and group or convention comps.
What we have not measured
- An unplanned failover. Planned switchovers are measured. A real, unplanned loss of a site has not been, and replication is asynchronous, so the last few in-flight writes could be lost.
- Sustained load. The decision time above is for single requests. A test at hundreds of decisions a second is written but has not been run.
- A restore from off-site storage. There is no off-site copy yet to restore from.
- A real property's data. Everything here has run on a demonstration property's records. There is no pilot yet.
What we got wrong, and fixed
We keep an internal log of our own mistakes and read it before every change. These are the recent ones that touched what this page describes.
| When | What was wrong, and what we did |
|---|---|
| 12 October | Our site described a two-way multi-site setup, an offline mode, signed decisions and back-testing on months of history. None of those existed, and three market statistics did not match their sources. We audited every claim against the code and the running system and removed what was untrue. We then built the missing capabilities (offline allowances, signed events, outside timestamps, back-testing) and restored the claims only with their limits. |
| 13 October | A patron's daily spend limit counted the UTC calendar day instead of the property's gaming day, and a “rolling window” was only a copy of the daily total. Both are fixed, and a test fails if either returns. |
| 13 October | A welcome promotion could be issued automatically to an uncarded player who was losing heavily, under licences that are meant to hold such offers back, because a new member record has no history for the gate to read. It is now withheld, and tests cover every licence and every path. |
| 13 October | Our hosted demonstration signed users in through a development shortcut that let anyone holding the shared password act as any user. It now uses per-login identities with signed, short-lived tokens, and every datastore password was rotated. |
How we keep this page honest
Every statement here comes from an internal register in which each capability is marked built, partly built or not built, and checked against the code and the running system. An automated test fails our build if a claim we have retired, or a claim without its limit, comes back onto the public site. This page is dated and revised when a status changes.
If a line here is not true when you check it, tell us. That is a defect, and we will fix the page or the product.
See it, and ask us about the gaps
A demonstration shows the decision, the audit record and the limits above on a working system.
Book a demo →