Legal review

Why

A rule of law does not become enforceable in the product until it has been reviewed by an authorized lawyer — never because a developer coded it in good faith. This process organizes that review so that every cell of the collateral reference framework used in production has actually been validated by someone who bears responsibility for it.

How, in the application

A rule moves through a four-position state machine: PROPOSEE_A_VALIDER (proposed, to be validated), then, after validation, VALIDEE_CONSEIL (validated by counsel), and finally, after a second, distinct act, ACTIVEE (activated) — only this last state makes the rule usable in production. The distinction between the last two states is deliberate: counsel can state what the law allows without anyone having yet decided to use it, for example because an engine is not ready or an operational question remains open. A correction position (A_CORRIGER, to be corrected) lets a proposal be sent back upstream without losing it.

Three distinct authorizations govern these acts: reviewing, commenting, and requesting a correction are open to a reviewer; loading a proposal into the review space is open to a rule editor, who carries no validation power. Validating and activating are both reserved to an approver, registered by name with the firm and the source of their authorization. Every correction of an already-proposed rule creates a new version rather than overwriting the previous one — a rule reviewed six months later must be able to show what was submitted and what counsel answered at that time.

The base reference framework covers twenty-two OHADA collateral regimes, supplemented by country-specific national overlays; a cell that is not validated or is explicitly marked unavailable can never be used by default — any operation that encounters it is blocked and explicitly escalated to a human, rather than receiving a default value that would silently produce null collateral.

Safeguards

• Loading a proposal and validating it are two acts of a different nature, deliberately held by distinct authorizations: linking the two had the perverse effect of leaving the review space empty, for lack of an available approver to feed it.
• A fictitious rule set, used for demonstrations, is locked so it can never load in production — the rule is enforced both in the code and in a dedicated database column, so that a database restored from a demo environment cannot unlock this fictitious set in production by the mere virtue of its data.
• An incorrect default would be worse than a block: a block costs a phone call, null collateral costs the financing's principal.