If you can't explain why that case was approved, the problem isn't the archive.

Usually not. A mature case management system handles master data, accounting entries, commissions and reporting to principals: replacing it is a risky project that rarely pays.

Pwas covers the layer that's generally missing: rule-governed processing. It takes the case in hand, applies the controls, manages the queues, the waiver authorities and the decision trail, and returns the outcome and required data to the case management system. That system remains the ledger; Pwas becomes the place where you can see why things went the way they did.

In some firms the scope widens over time and functions move across. That's a choice taken later with evidence in hand, not a prerequisite.

That's exactly what makes this approach interesting for a compliance function, and it's the most concrete difference from a traditional application.

In a classic system, processing rules are code: to know what the system actually does you have to ask IT or the supplier, and the answer is a second-hand description. The control function verifies outcomes, not the mechanism.

Here the rules are a readable structured document — which controls exist, with which thresholds, with which effective dates, who can waive and under what conditions — and that document isn't the system's documentation: it is the system. There can be no gap between what is written and what is applied, because they're the same thing. A control function can read it, compare it with internal policy and spot differences without going through anyone.

Verification work on individual cases obviously remains. But the nature of control changes: from reconstruction to reconciliation.

It's one of the most common requirements and one that creates the most work in traditional systems, because access separation ends up implemented in every screen, every report and every interface — with the risk that somewhere it gets forgotten.

In the declarative model the rule is written once, at data level: an agent sees the cases they own, with certain fields visible and others not; an area manager sees their network's; a control function sees everything but cannot modify. The same rule holds in screens, portals and automated flows, because the system enforces it in one place instead of each application remembering to.

The practical benefit is that opening a new channel — a portal for the network, a data exchange with a principal — stops being a security project of its own and becomes a declaration of which data that channel may see.

It becomes an unacceptable risk at the exact moment you put it in charge of deciding. A merits assessment cannot depend on a probabilistic model, both for regulatory reasons and because you wouldn't be able to explain it.

It has concrete value in three places. Reading inbound documents: payslips, registry extracts, identity documents, policies and surveys arriving as scans are read and their data proposed pre-filled, with human verification. It's the heaviest cost item in a back office and the dullest work in it. Completeness and consistency checking: flagging that a date doesn't add up or an attachment doesn't match its declared type, as a flag to verify and not as an outcome. Precedent search: finding how analogous cases were handled, with a natural-language question.

The structural guarantee, in a sector where this is the first question any auditor asks: the agent has no free access. Every action goes through a plan verified against the real permissions of whoever requested it, sensitive actions require explicit human confirmation and every step stays traced. An agent doesn't approve, doesn't decline, doesn't waive and doesn't contact the client: it prepares worked-up material for whoever has the authority to decide.