In forceDecided on 12 October 2026 · Ref. RF-102
Interface: reloads only when the data changes
- What the tool does
- Screens reload only if the data has actually changed (a lightweight fingerprint is checked regularly); a change made from the session reloads immediately. A session reads the database through a read-only connection, opened for the duration of a display. An engine version that could not be checked is treated as incompatible, with an alert. Failed login attempts are counted and capped, and the screen says how long to wait.
- Why
- Reloading on a timer reopened the database dozens of times per display, and holding a connection longer would prevent writing. A contract that could not be read is not a compatible contract.
In forceDecided on 11 October 2026 · Ref. RF-052
Contact printed on documents sent to the supplier
- What the tool does
- The supplier request and the footer of the negotiation file print a function (“Purchasing department”, or its equivalent in the document's language), never the buyer's identifier. A setting can restore the buyer's identifier.
- Why
- A document sent outside the company must not carry personal data it does not need (GDPR).
In forceDecided on 11 October 2026 · Ref. RF-072
Entity connected through Snowflake, read-only
- What the tool does
- An entity whose ERP data sits in a Snowflake warehouse is connected by configuration: one declared query per data set, a dedicated role and a key pair. Administration roles and passwords are refused; each query is a single read, checked before it runs. A data set is read in full or not at all. A dry run checks the connection, the role, its rights and the columns, without reading data or writing anything. Proven in simulation; the test on a real account is still to be done.
- Why
- The tool's account must not be able to change anything in the group warehouse, and a truncated data set would read an absence as a removal.
In forceDecided on 11 October 2026 · Ref. RF-084
Simulated ERP mode: never by default, always flagged
- What the tool does
- To prepare a connection, the tool can read a fictitious ERP from a local database, with the same queries and the same checks. This mode is never active by default; it is refused as soon as a real entity or real data is present, and it is flagged wherever it acts (synchronisations, reports, dry run).
- Why
- Fictitious data mixed with a real site's data could no longer be separated from it, and an “all green” report on a simulation proves nothing about a real connection.
In forceDecided on 10 October 2026 · Ref. RF-060
Purging the demonstration database
- What the tool does
- Only an administrator can purge a demonstration or test database: operations approval, plan, reason, confirmation phrase and a verified backup before anything is deleted. Operations can reinstate approval by a second administrator.
- Why
- The existing safeguards are enough for a demonstration database; a second administrator blocked its use.
In forceDecided on 12 October 2026 · Ref. RF-073
Database chosen at installation
- What the tool does
- The database (DuckDB or PostgreSQL) is chosen at installation; DuckDB is the default. Moving to PostgreSQL is a one-way migration, supported following a written process: each table is copied in full, its rows counted and its totals compared; at the slightest gap, the migration is refused and DuckDB remains the database. The original database is kept intact. An operations check recommends migrating beyond certain thresholds, without switching anything by itself.
- Why
- Switching live would show an empty database or two diverging ones; an unverified migration could lose history without anyone noticing.
- Where to see it
- Entities, ERP & rates
- Database
In forceDecided on 12 October 2026 · Ref. RF-090
Database settings changed by the administrator, with safeguards
- What the tool does
- Only the administrator changes the PostgreSQL connection settings. They authenticate again (password, or a one-time code from an authenticator app behind the company portal). A connection test precedes any change; an alert reminds them of their responsibility and asks for explicit confirmation. The password is never displayed or stored in clear. Every change is logged and the previous configuration can be restored in one step. A change to the live database goes through maintenance mode.
- Why
- A wrong setting stops the tool for everyone, and a change made while others are writing can lose data. The test, confirmation and maintenance prevent the error; the log and the restore repair it.
In forceDecided on 11 October 2026 · Ref. RF-083
Interface translation: no external service
- What the tool does
- French is the source language. Each text has a stable key, in a single set of files, one per language. A missing translation is never a raw key or a blank: the interface shows the French text and flags it. No translation is requested from an external service. Adding a language requires no code change. Your data (suppliers, descriptions, references) is never translated.
- Why
- A purchasing tool used in several countries must speak each user's language without texts leaving the company or a missing text breaking the screen.
In forceDecided on 11 October 2026 · Ref. RF-081
The workstation's MAC address is never collected
- What the tool does
- The export and archiving log never records a MAC address, at any traceability level, and no setting allows one to be passed. At the most detailed level, the log records the truncated IP address, and nothing else about the workstation.
- Why
- Behind the proxy server, the application cannot see the workstation's MAC address: the value written would be wrong. GDPR data minimisation points the same way.
In forceDecided on 12 October 2026 · Ref. RF-096
IP address in the export log: absent by default, truncated, 12 months at most
- What the tool does
- By default, no IP address is collected, even when provided. At the “full” level, chosen by your IT department, only the truncated address is written (IPv4 to /24, IPv6 to /48); the full address exists in no line. The line carries its purpose (“security”) and its retention end date: 12 months at most. Expired lines are proposed for purging; the chained log is never rewritten by the tool.
- Why
- An IP address is personal data; GDPR minimisation requires keeping only what is useful, and the security purpose is met by a truncated address. Your legal department reviews the duration and purpose before any use at the “full” level.
In forceDecided on 12 October 2026 · Ref. RF-097
Retention periods by document type
- What the tool does
- Invoices, orders and receipts: 10 years after the financial year closes. Price lists, contracts and letters: contract term plus 5 years. Technical logs: 12 months. Each archived document carries a retention label (type of period, calculation basis, end date). An unknown basis (year-end not declared, contract end unknown) leaves the end date empty with its reason: it is never guessed and the document is never proposed for deletion.
- Why
- A guessed end date would delete accounting or contractual evidence too early. These periods are to be reviewed by your legal department.
In forceDecided on 12 October 2026 · Ref. RF-098
The tool proposes, IT deletes
- What the tool does
- The list of retention deadlines is read-only: it proposes, it never deletes anything. Deletion remains an act of the IT department, logged, requiring an active setting, a written retention rule, a dedicated right, a reason, a confirmation and a recorded legal review; without it, confirmation is refused. A document with no end date, not yet expired or under legal hold is never deleted.
- Why
- The tool proposes, IT executes with a trace, and until legal has reviewed the periods, nothing is deleted.
In forceDecided on 19 October 2026 · Ref. RF-147
The exports journal is cut into sealed months, IT deletes an expired month by hand
- What the tool does
- The exports and archiving journal is cut into one file per month. Each closed month gets a seal (period, number of lines, first and last fingerprint, file fingerprint) kept in a file next to it, in the database and, if a data lake is declared, in the data lake; the first line of the next month continues from the last fingerprint of the previous one, and no existing line is ever rewritten. A month can be deleted 12 full months after its last day. Deletion is a manual act of the IT department, never automatic: reserved to the administrator, with a dedicated right, a reason and a confirmation (otherwise a mere preview), on the oldest month only and only once legal has reviewed the periods; otherwise refused and logged. The seal stays, chain verification restarts from it, and a month that disappears without a recorded deletion is flagged as a break. Consequence: a line can be kept up to 13 months instead of 12, which legal must settle.
- Why
- Removing expired lines by cutting the start of a chained journal would break the chain of fingerprints. Sealed months are deleted whole, the seal keeps the proof, and nothing disappears without a human, logged decision after legal has reviewed it.
In forceDecided on 12 October 2026 · Ref. RF-103
Database sizing based on measurements
- What the tool does
- The database size recommendation is based on waiting times measured on a copy of the database, with the real service: writes under 2 seconds and reads under 1 second for 95 % of requests. Any sizing value that was not measured is written as “estimated”, with how it was calculated. PostgreSQL fed by DuckDB is chosen for volume, failure recovery and backup, not to serve more users.
- Why
- Migrating to fix a wait that does not come from the database would cost a migration with no effect, and unmeasured figures presented as exact would lead to wrong purchases.
In forceDecided on 13 October 2026 · Ref. RF-105
Display formats follow the language; the currency follows the data
- What the tool does
- Numbers, amounts, dates and percentages are displayed according to the screen language (separators, month names, symbol position). An amount's currency always comes from the data: changing language moves the symbol, never the currency. Files produced for other tools (extracts, ERP export, workbooks) keep their format, whatever the screen language.
- Why
- An amount in pounds shown in euros because the screen is in French, or an ERP export whose decimal separator changes with the language of whoever produced it, would distort a price comparison or an ERP load without anything flagging it.
In forceDecided on 13 October 2026 · Ref. RF-106
Interface language: the profile choice comes first
- What the tool does
- A session's language follows the choice saved in the person's profile, otherwise the browser's, otherwise French. Everyone chooses their language in the Display menu; the choice changes neither their rights nor their data. A text shown in French for lack of a translation is marked “[FR]” only for the administrator, never in the files produced.
- Why
- Someone working in German must not fall back to French because they changed computer; a marker visible to all would cast doubt on the tool, while the administrator needs it to spot what remains to be translated.
In forceDecided on 13 October 2026 · Ref. RF-111
The test suite also runs on PostgreSQL
- What the tool does
- The tool's test suite runs on both database engines. Tests that already pass on native PostgreSQL form a versioned list: a test on that list that fails makes the suite fail, and a test passing outside the list is flagged to join it. Without a PostgreSQL server, the run stops instead of skipping every test. The ordinary suite is unchanged.
- Why
- Translating every view and query without silent regressions requires knowing, test by test, what already works, and never losing a test once it passes.
In forceDecided on 13 October 2026 · Ref. RF-110
A single access layer; native PostgreSQL still refused
- What the tool does
- Every access of the tool to its database goes through a single layer, designed for DuckDB (the default) and for PostgreSQL through a native driver. Until all views and queries are translated for PostgreSQL, this native mode is refused with a message saying why and what to declare instead; the tool never opens another database in its place. The driver is an optional dependency, loaded as a separate library.
- Why
- Moving to PostgreSQL in stages without breaking what exists requires a single place where the engine is switched. Accepting the new engine before everything is translated would serve errors instead of a clear refusal.
In forceDecided on 20 October 2026 · Ref. RF-158
A new customer starts directly on PostgreSQL, never overwriting a database
- What the tool does
- A new customer with no data at all can start on PostgreSQL on day one, without going through the migration: a plain-words preview first says what will be created, then the administrator confirms. The tool refuses to create in a database that already holds data and points to the migration instead. It checks the database it created, creates the indexes and recommends settings for the PostgreSQL server, without ever applying them itself.
- Why
- Going through DuckDB and then the migration would be a detour for a customer who has nothing to copy, but creating without safeguards could one day overwrite a database full of data. Operations stays in charge of its server: the tool advises, it never touches its configuration.
In forceDecided on 13 October 2026 · Ref. RF-109
PostgreSQL indexes: a migration is never refused because of an index
- What the tool does
- PostgreSQL indexes are written in a versioned script and created table by table, right after each table is copied and verified. A unique index is created only on a key the tool guarantees, after counting duplicates in the real data: if there are any, the index is created without uniqueness and the report says so. An index never makes a migration fail.
- Why
- Without indexes, every filtered read scans the whole table. But a unique index on a key the data contradicts would make the migration fail: the check comes first, and the gap is reported, not hidden.
In forceDecided on 13 October 2026 · Ref. RF-108
Engine service: reads together, each write alone
- What the tool does
- The service protecting the database lets several reads run at the same time, each read-only, and runs each write alone. As soon as a write is waiting, reads arriving after it wait until it has gone through; nobody waits forever. A read made just after a write sees what was written. Only commands proven never to write run with the reads, and the database is opened read-only for them.
- Why
- A single lock made reads wait behind writes, although most requests are reads. Letting reads run together removes that wait with no risk to the data, since each write still runs alone.
In forceDecided on 18 October 2026 · Ref. RF-130
A randomly drawn demonstration world that can be replayed
- What the tool does
- The administrator can replace the demonstration data with a fictitious world drawn at random: suppliers, articles, prices, ERP exports for several sites and tariffs processed by the same commands as the screens. They pick a seed and a size; the same values give exactly the same world. Loading goes through the database purge, with all its locks, a verified backup and a refusal in production. This feature is switched off in a client delivery: it only serves training and demonstration environments.
- Why
- To show the tool on varied data without ever copying real data, and to replay a successful demonstration identically, without the screen being a way to empty a production database.
In forceDecided on 18 October 2026 · Ref. RF-149
One Word guide per role, always in step with the tool
- What the tool does
- Each profile has its own guide: mission, day, screens, rights, exchanges with the other roles and a training path. A roles map shows who depends on whom, and a deployment guide gives the order to put the tool into service. The guides are generated from the tool itself: they cannot say anything the application does not.
- Why
- To train a team role by role, without a manual of several thousand lines, and without a guide that goes wrong as soon as the tool changes.
In forceDecided on 19 October 2026 · Ref. RF-150
Simple settings are made from one screen, with a right closed per setting, a reason and a cancellable history
- What the tool does
- Each simple setting (a number, a yes/no, a choice from a closed list) is declared once in the engine. The "Settings" screen shows, for each one, the value in force, where it comes from (original value, client file, set here, supplier, entity) and the original value. Changing a setting requires a profile authorised for THAT setting, a value within the bounds (refused otherwise, never corrected) and a reason of at least 10 characters. Each change is a new version in the history and can be cancelled; two people changing the same setting at the same time do not overwrite each other. The most specific value wins: a supplier's or an entity's value comes before the whole company's. A missing value is the original value, never zero. A new value applies to the following campaigns; those already produced do not change.
- Why
- So that setting up a new client no longer means editing files on a server with no trace: each setting gets the same guarantees as the existing setting cards, without writing another screen for each one.
In forceDecided on 20 October 2026 · Ref. RF-159
Fictitious price lists are only built and filed on a demonstration base, and never take a decision
- What the tool does
- The tool can build realistic fictitious supplier price lists on demand (increase, decrease, varied file formats, mistakes, date shifts) to try the analysis, the alerts and the export. It only works on a demonstration or trial base: on a real base the application refuses before any reading or writing, and the screen offers nothing. The price list is filed like any other, cancellable and logged with a reason; the buyer then decides on screen. An expectations file says what the tool must find.
- Why
- Invented prices mixed with real ones in a base that is never erased would be irreparable: the lock is therefore in the application itself, not only in the screen. The whole journey can be tried without any real data.
Decided, to be deliveredDecided on 26 October 2026 · Ref. RF-176
The database can be read in SQL, read-only, by the administrator and the architect: delivered for the administrator, one query at a time, capped, interrupted after ten seconds and traced
- What the tool does
- The database can be queried in SQL, read-only, without ever being changed, by the administrator and the architect. This reading is delivered for the administrator alone, through an engine command; the screen will follow. The architect will get access once a verifiable filter hides the transfer prices, which the architect never sees; until then the engine refuses. The right is checked by the engine itself, not only by the screen, according to the accounts registry; an unknown or deactivated account is refused. A query is a single read statement: writing, creating, deleting, settings, reading a file or the network, and two statements in a row are refused. Only the interface views can be read; a raw table, an internal view or the engine catalogue is refused, wherever it hides in the query. The result is capped (a thousand rows by default, five thousand at most, twenty megabytes at most, with a "truncated" flag and its reason), the query is interrupted after ten seconds, and an absent value stays absent, never zero. Every call, accepted or refused, leaves a line in the chained journal (who, which query, how many rows, how long, what outcome as a closed code), never the content of the result nor an engine error message.
- Why
- The database holds commercial data that not every profile may see. A free query would bypass the interface's masking rules: for now the engine therefore reserves this reading for the administrator, caps it, and keeps a trace of it.
In forceDecided on 26 October 2026 · Ref. RF-180
An entity can be declared "demo": it is counted apart in the system health measures and never mixed into real totals
- What the tool does
- An entity can be declared "demo" in the configuration, by a simple true or false property (false when it is not declared). The tool shows it as is in the entity list, never empty, and a value that is neither true nor false is refused when the configuration is checked: the entity then stays a real entity. A database already in service receives the property as false for all its entities. The “System health” screen, reserved to the administrator and the data architect, counts demo entities apart and never mixes them into the totals of real entities: a folded block lists them with their expected failures. The demonstration world thus flags all its deliberate error-case entities, and only those.
- Why
- The demonstration world contains entities that fail on purpose. Without an explicit signal, a system health screen would count them as real outages: whoever builds the demonstration says which entities are fictitious.
In forceDecided on 21 October 2026 · Ref. RF-160
Everyone chooses their own display, and the choices follow them from one workstation to another
- What the tool does
- The "Display" menu offers each person five choices, kept on their own account: the home page ("To do" or "Overview"), the menus (detailed, with an explanatory line under each screen, or compact), the counters of the bar (how many deduced tasks are waiting behind the home page, each menu and each screen), the screen help boxes (folded or always open) and the density. One button restores the default settings. These are preferences, not rights: they change neither what the person is allowed to see nor the data, and a counter or a card never leads to a screen the profile does not have. At the top of "To do", one card per screen says how many tasks are waiting there and what they weigh, and opens it in one click.
- Why
- A buyer's day moves from one screen to another: nothing in the bar said where the work was, and the explanation boxes pushed the useful content below the fold. A beginner wants the help open, an expert wants a sober bar: each person sets their own screen without touching anyone else's.
In forceDecided on 21 October 2026 · Ref. RF-161
ERP data loads are scheduled by the tool, at adjustable hours, without blocking users
- What the tool does
- A scheduler built into the tool decides when to copy each ERP's data, per entity and per family of data: once a day, every 2 h, every hour, every 30 min or a number of minutes, inside a time window, on chosen days, in the entity's local time. Outside the window nothing starts, and on return a single pass catches up. The ERP is read without blocking anyone; only the short final write takes the lock, and its duration is measured and shown. An unchanged source costs no write. Never two loads at once, never during a backup. Sales are copied as a daily aggregate, never movement by movement. The scheduler is off until someone switches it on.
- Why
- A load that reads the ERP while holding the lock blocks every user for its duration (6 seconds at 100,000 articles, half a minute at 500,000). Reading without the lock, writing nothing when nothing changed and setting the hours limit the compute load and the growth of the database.
In forceDecided on 21 October 2026 · Ref. RF-165
The trial world only moves by what changes; a pass with nothing to do touches nothing
- What the tool does
- The trial world makes the seven fictitious sites live their ERP. It moves one step: a closed day on the daily step, a closed month on the monthly step. A pass where no day is due does nothing at all: nothing is replayed, nothing is rewritten, the trial stays exactly where it was. A pass where days are due no longer writes the whole history from the first day: it writes only what changed since the last pass (the prices entered by the sites, the new orders, invoices and volumes, the sales of the current month, the stock of the last day). The result is the same as a full run: same data, same files, same journal, same ground truth. If the simulated ERP folder no longer matches the state of the world (a world copied without its ERP, an ERP replaced by hand), the full run is done again: the trial never shows a mixture of two histories. With a fixed seed, the same history, day by day or in one go, gives the same result.
- Why
- Every pass replayed the world from its first day, while most nights had nothing to do: on the fastest machine, a pass with nothing to do already cost more than six seconds with three years of history, and writing the whole ERP from the origin was two thirds of a full pass (the server, with its slower disk, was hit much harder, one pass per night). The trial must move fast and never mix two histories.
In forceDecided on 21 October 2026 · Ref. RF-164
The reasons shown by the tool are a code, translated into the user's language
- What the tool does
- When the tool explains a line — a saving, a ranking, an alert that has woken up, an exchange rate, a suspension, a refused filing — it writes a code and keeps the French sentence as the reference. The interface reads that code in the translation catalogue: in French, the tool's own sentence, word for word; in the other languages, its translation. A reason the catalogue does not know stays displayed as it is, never empty, never as a technical key.
- Why
- A user whose language is not French was reading French in the middle of their lines. Recognising the sentence to translate it is fragile: one more word and the French comes back. The code does not move, and the French sentence displayed does not change.
