FenoriTechnologies
Selected Builds

Work Removal

Remove work without removing control.

We built Work Removal: a system that closes classes of repetitive work without individual manual review, strictly under conditions the institution has defined and approved, with every action recorded, evidenced and reversible.

StatusReference architecture
Institutional problemRepetitive low-risk review consumes analyst capacity
Technical foundationPolicy evaluation gate, versioned policy store, closure records
Existing systems retainedThe institution’s alert and case workflow
Human authorityPolicy defined and approved by the institution; unmatched cases route to human review
Evaluated onQualified-closure precision, evidence completeness, reopen traceability
DemonstrationArchitecture walkthrough on request
DataSynthetic
DeploymentInstitution-governed AWS environment
TypeGoverned automation systemDomainFinancial servicesStatusReference architectureComponents6

The institutional problem: repetitive review that changes nothing.

Analysts close large volumes of near-identical, low-risk alerts every month: the same pattern, the same disposition, no judgment actually exercised. The work consumes the institution’s scarcest resource without changing any outcome.

Automation is easy to describe; governed automation is much harder. In a regulated environment, removing a human action cannot mean silently allowing a model to decide which work no longer matters.

Inputs and source systems.

Human judgment moves upstream: instead of making the same low-value decision one case at a time, the responsible owner defines the policy governing that class of decisions, and the institution approves it.

  • Cases and alerts entering the workflow
  • The institution’s approved closure policies, versioned
  • The entity context each case carries

How the system is composed.

What happens when an event enters.

Case enters
↓
Evaluate against institution-approved policy
↓
Does it satisfy every required condition?
↓
NoNormal human review
YesGoverned no-touch path
↓
Record basis + evidence + policy
↓
Close under policy
↓
Remain reopenable and subject to future review

Core technical components.

  • Policy-defined eligibility gate
  • Versioned policy store
  • Governed no-touch closure path
  • Closure recording: basis, policy, evidence
  • Reopening mechanism
  • Human authority layer

Control logic: evaluate, route, record

When a case enters, it is evaluated against every condition of the applicable approved policy. A case that fails any condition routes to the normal human review path, unchanged. A case that satisfies all of them closes under policy: recording the basis on which it qualified, the policy version that authorized the closure, and the supporting evidence.

The exception path is the default path: anything the policy does not explicitly qualify goes to a human. The automation operates only inside the boundary the institution has drawn.

Example: a policy-governed closure class.

An institution’s analysts close roughly 400 alerts a month generated by salary batch payments from Fjordlink Payroll AS: a pattern reviewed and dispositioned identically every time. Entities and figures in this walkthrough are synthetic.

  1. The responsible owner defines the closure policy for this class: known originator, amounts within the established band, recipients previously seen, no concurrent signals on any involved entity. The institution approves it as policy version 1.
  2. A new alert in the class enters and is evaluated against every condition. It satisfies all of them and closes under policy v1: recording the qualifying basis and the evidence checked.
  3. A similar alert arrives where one recipient is new. It fails a condition and routes to normal human review. The analyst sees why: which condition failed.
  4. Five months later, new intelligence raises the risk on one recipient entity. Previously closed cases referencing that entity are identified from the closure records and brought back into scope.
  5. The institution can state, for every removed case: what was removed, why it qualified, under which policy version, and what evidence supported it.

How it sits inside the institution.

Evidence and audit behavior

A removed case does not disappear. The system retains what was removed, why it was eligible, which policy version authorized it, and what evidence supported it: so the institution, its second line and its auditors can examine the removal after the fact.

Where human authority remains

Humans define the policy. Humans define the boundaries. Humans retain authority over consequential outcomes. The system executes the approved policy consistently and records what it does.

Working with what already exists

Work Removal sits inside the institution’s existing alert and case workflow. It does not replace the review path: it narrows what reaches it, under policy.

What the system outputs.

  • Closures executed under approved policy, with basis, policy version and evidence recorded
  • A reviewable register of removed work
  • Reopen candidates when policy, intelligence or context changes

What it deliberately does not do.

  • The system does not independently decide which work stops being reviewed: eligibility exists only inside a boundary the institution has defined and approved.
  • The objective is not maximum automation; work that requires judgment continues to receive it.
  • Nothing is removed silently. Every no-touch closure retains its basis, policy and evidence, and can be examined.
  • No closure is an irreversible blind spot: removed work remains reopenable when the picture changes.

Automation should remove repetitive work. It should not remove accountability.

Related builds

Built around your problem, not this one.

An institution may need this build, part of it, or something entirely different. The institution determines the outcome. The technology follows.

Discuss this outcome