Four-eyes framework

A part is a function that must approve: controller, finance, market_risk, operations. A lookup of parts says, for each, the permission its decider needs and its place in the order. A request's parts are the distinct parts of its changes.

A decision records the part it answers, and the decide function approves the request only when every part has an approval from a person who holds that part's permission. A refusal from any part ends it. A part with an earlier place in the order cannot be answered until the earlier part has approved. The existing rules carry over unchanged: the person who asked never decides, one person approves a part once, a refusal needs a comment, and a decision names the version it saw.

The count the kind keeps, approvals_required, still serves the kinds with one part, such as the role request, which names a single part with its permission.

The policy is data: a row says that an act on an entity, optionally narrowed to a set of fields, needs a named part. Changing who decides is a data change. The system tenant holds the rows, and a tenant may add a part to an act but never remove one the system names, so a tenant cannot loosen its own controls. A tenant without a Market Risk function does not edit the policy: it grants the part's permission to whichever role does that work, since a part is decided by a permission and not by a named job. The rows are the tables in Book types and the controls on each: the description of a book needs no part, the cost center needs finance, and so on. An act with no row is written directly.

A request holds a list of lines. A line is one proposed write, held as a typed row of the entity it changes, in a table of its own. This is what the role request already does: its detail is a typed table keyed by the request, in the component that owns the kind, and nothing in the inbox is stored as a document. The pending table of a gated entity has the entity's own columns, with the same foreign keys, checks and lookup validation, plus the request, a line number, the operation (put or delete) and the version the maker read. A line holds no part. A put can change columns that two parts decide, so the request holds the parts, as the union the policy gives for the columns all its lines change. The pending table is generated from the entity's model, as the entity's other tables are, so a model change reaches the pending table in the same regeneration and the same migration. A request may hold lines for several entities, one typed table each.

An entity model opts in with :gated: true in its * Flags drawer. The code generator then derives a second entity model, <entity>_change, beside the first, and runs every existing template on it. The derived model has no natural keys and no checks or insert-trigger rules, because those are the live row's rules and the dry run runs them by calling the real write. It is read-only to clients: only the raise operation writes a line. compass codegen generate derives it whenever it generates the gated model, and a drift check fails when a derived model is stale. A model can hold its changes before it enforces the gate. :pending_change: true derives the same pending model and its stack and leaves the entity's writes direct. :gated: true does both. A junction can carry either flag: its pending model holds the two halves as plain columns.

The queue and the request page need three further typed facts that no entity table can give: the parts a request needs and their order. They live in one small table keyed by the request and the part, written at raise.

One generated operation raises a request. Its message is typed: a reason, and for each gated entity a typed list of proposed writes, in the shape the entity's put already takes. It does four things in one transaction:

1. It runs each write through the real service's database layer inside a savepoint and rolls the savepoint back, so every refusal the service would give, such as a level violation or a stale version, comes back to the maker at once, before anyone waits. The dry run covers database rows. A sequence value it used stays used. It publishes no event and sends no notification, because it calls the repository and validation layer and never the layer that publishes.
2. It reads the policy for the columns each line changes and gives the request the union of the parts. A request with no part is refused here as "needs no request", so a caller writes it directly. The policy names the columns of the entity, and a line that creates a row changes every column.
3. It writes the request, its parts and its lines.
4. It tells the deciders of the parts that can be answered now: the first part in the order, or every part when the policy gives no order.

A preview operation does steps 1 and 2 and writes nothing. The web calls it from the review, so the review can show every change with its decider before the person confirms.

The checks a decider reads, such as that the book is flat, that the owner unit is in the ancestry chain, and that the row is still at the version the maker read, run against the live row and the typed pending row. They run at raise, so the maker sees a failure early, and again at apply, because the live row may have moved.

A part later in the order cannot be answered, and so cannot refuse, until the parts before it have approved. A refusal from a part that can be answered ends the request. The notification goes only to the deciders of the parts that can be answered now.

The wait for a person stays a record, not a workflow. The engine cannot wait on a person: its states are pending, in progress, completed, failed, compensating and compensated, nothing suspends a run, and a wait is a bounded budget whose expiry is a failure (Waiting, deadlines and cancellation). A decision may take days. So the parts, the order, the decisions, the expiry and the reminders are the record's own state.

What happens after the last approval is a process, and the engine is built for it. The approval's change event starts an apply workflow for the request. Its steps are each idempotent and each states a deadline:

1. Re-check. Run the checks again against the live row and each typed pending row, because the live row may have moved since raise.
2. Apply. Apply every line in one transaction, through the same service code the direct write uses, as the approver with the request as the reason, as IAM does for roles. Each line is marked applied in the same transaction, so a line applies once.
3. Tell. Tell the person who asked, and the deciders, that it applied.

The definition's failure policy is stop, as provisioning's is, because the work that matters is one transaction that either happened or did not, and the recovery wanted is a retry and not a rollback. A failure is one of two kinds, and the difference decides what happens:

• A refusal from the service, such as a stale version or a validation rule, is permanent. The apply step rolls the transaction back, moves the request to apply_failed with the line and the reason, tells the person who asked, and ends the run as failed. A refusal is never retried, because the answer cannot change.
• An infrastructure failure, such as a service that is down, or a missed deadline, is transient. The run stops with its completed steps kept, the request stays approved, and the engine's retry verb resumes the run. A scheduled retry calls the verb until the kind's window ends, and then the request moves to apply_failed with the reason "could not apply", so a request never retries forever.

This replaces the hand-written reconciliation the role request uses. The run shows on the same workflow screens as provisioning, so an operator sees an apply that is stuck and why. The role request can move onto the same workflow later.

apply_failed is terminal, like refused, withdrawn and expired. The maker raises a new request from the current row, and the new request needs every part to approve again, because an approval is a decision on one proposed row and the new request proposes a different one. The request page offers "raise again", which carries the lines forward re-based on the current row so the maker does not retype them.

The gate sits in the generated service of a gated entity, below every handler that serves it, so a script, a hand-written handler or another client meets the same rule. The put, the batch put, the delete and the batch delete each ask the policy first. The service compares the proposed row with the live row, and a row that is new changes every column. The policy names a part for the act, or it does not. When it names none, the write goes ahead as before. When it names a part and the write does not come from an approved request, the service refuses with the typed result approval_required, which carries the outcome denied, and writes nothing.

The apply is tied to a request, not to a caller. The applier tells the service which request it carries out. For each write the service checks, in the same transaction, that the request is approved and holds an unapplied line for exactly this entity, key, operation and version. Nothing the caller can set opens the gate: only rows in the database do. The request is never a field of a message a client sends. It is set in process, by the applier alone. The preview runs the real writes in a transaction it never commits, so it marks the service as a rehearsal and the gate lets those writes through. The service's own in-process save and remove methods take no request, so a gated entity refuses them: the protocol operations are the only way to write.

A gated junction has the same gate on its put, its batch put, its delete and its batch delete. A link has no columns of its own, so the service asks the policy with none, and a policy row that names no column covers the link. The line the request holds names the link by its two halves. The policy names the junction by the name of its model, for example party_counterparty.

A hand-written handler, such as a composite write, reaches the store through the same service, so it meets the same check. A write that does not use the service does not meet it. The SQL that publishes a dataset into the tables is one such write. Whether the policy should cover it is a separate decision.

Six states exist today:

apply_failed is added, and it is final. The decision types stay: approve, refuse, hold, resume, withdraw. A part's answer is a decision carrying its part, so the history shows who answered which part and when, with no new table of answers.