eRegulations-Next: concept note

One product in its 7.x line, deployed per country, built from three applications that must be released together.

Each country is one Coolify application and a SQL Server 2022 Express database, plus three databases shared between countries (consistency review, statistics, a legacy global one) and four mounted folders of files: media, the home page's configuration, public content, interface labels.

The fleet: 7 instances on 7.x (Burundi, Comoros, Iasi, PAST, pilot-tradeportal, South Sudan, lab-next) and about 90 legacy instances in 4.x and 5.x, about 200 groups, on four Windows servers.

TradePortal is not a mode. It is the same code with modules switched on by configuration: the duty and tax calculator, HS code search, products, the administrative burden cost (ABC).

The same product, with the same functions and the same addresses for those who read it from outside. Nothing a country uses today is lost D1.

For the public: the home page and its menus, search by filters and by words, procedure summaries and step sheets with their requirements, costs, timeframes, results, laws and contacts, the directories, printing, embedding in another site, feedback, in each language the country publishes, right to left included.

For a country's team: the procedure tree of objectives, blocks and steps, the catalogues (institutions, units, people, documents, laws, cost variables, filters), site content and layout, publishing with its versions and audit, translations, users and roles, consistency review and step statuses.

For TradePortal countries: the modules a setting switches on, as today.

One application and one database per country. The public site and the API read only published documents; everything else a country changes is a setting, not an environment variable.

One Next.js application holds the public site, the back-office, the API and the pages meant for embedding, on Postgres, aligned on Academy-Next D7. One image serves every country; each country is a deployment with its own database D2.

A published procedure is one document. The draft is kept in normalised tables. Publishing writes a version of the whole procedure, in every language, that the public site and the API read without another query. Today's equivalent is twenty denormalised Snapshot_* tables per language.

Text is translatable everywhere in one way: each field holds its languages together, falling back to the country's default language. Today each table has a sister _i18n table, named inconsistently.

Settings live in the database and are changed from the back-office: languages, default currency, modules, analytics, mail, layout, the country's CSS. The environment holds only the database address, the sign-in secret and the media folder. Today about 25 environment switches and Razor parts supplied per instance do this.

Sign-in is local to the instance: a name and a password, no Keycloak D3. Passwords imported from today's bcrypt, SHA-256 or clear text are kept or re-hashed at first sign-in; none is ever sent in a URL.

A country moves by loading its backups into the new model. The import can be repeated as often as needed; the switch is one more import, then a change of address.

The source is SQL Server backups only; no instance exports anything else. The importer restores them in a throwaway SQL Server, brings a legacy database up to the 7.x shape with the scripts the provisioner already uses, reads it table by table, transforms each domain with a pure function, and loads everything in one Postgres transaction. Original identifiers are kept for everything an address or the API points at D8.

It stops without writing when a backup cannot be read, a schema is not recognised, two user names differ only by case with no rule to merge them, or the target is not empty.

Its report counts each kind of item in source and target, lists rejected rows and anomalies, and compares the cost and timeframe totals of twenty published procedures with the live site's.

The day of the switch: editing frozen in the old back-office, a final import, the report read, the address switched.

Other systems read eRegulations every day. They keep working the day a country moves, without changing anything.

The modules come back as settings of the installation. One of them already has its own project.

Seven steps, each through four marks, as for the tariff calculator. Nothing is drawn or built before a step is signed off D9.

The marks are: written, agreed in principle by melux, checked by reviewers (Claude and Codex, each on their own), signed off with its date after colleagues' comments.

The six lots of 24-09-2026 D5 become the phases of step 7, in the same order D6.

Step 2's fourteen modules, proposed: 0 public site · 1 search and filters · 2 procedure and step pages · 3 directories · 4 public API and embedding · 5 procedure editing · 6 catalogues and media · 7 publishing and history · 8 translations · 9 users, roles and sign-in · 10 review and statuses · 11 TradePortal modules · 12 import and switch · 13 running it.

pilot-tradeportal proves the import; a live country proves the switch.

Before its switch, each country's installation runs at <country>-next.eregistrations.dev, and takes the country's current address on the day of the switch D14.

Rehearsal: pilot-tradeportal. Imported at the end of 7.1, its report read with no unexplained difference, its pages compared with today's site once the public site exists (7.2).

First switch: a live 7.x country, not chosen yet (?2), once the back-office lets its team edit (7.3), and the TradePortal modules if it uses them. The legacy instances follow, in an order step 6 sets.

Eight decisions of 24-09-2026 are recorded as D1 to D8; four of 01-10-2026 set the way of working, and three more answer this note's questions. One is deferred: which live country switches first.