Resilience Solutions

Proof

Client work, published the way it should be.

We publish a case study when a client has approved it in writing and the results can be stated with a timeframe and a baseline. That standard is why this page is currently shorter than it will be.

Awaiting client approval

There is no client work on this page yet, and we are not going to invent any

A page of unattributed “a leading retailer” stories with unverifiable numbers would tell you nothing you could rely on. Approvals are being sought for completed engagements, and studies appear here as each clears client and legal review.

What follows instead is a capability study: the same structure, the same level of detail, with method in place of a client name. It is a better guide to how we would approach your problem than an unverifiable success story would be.

Capability study · no client named

Shortening medical review without cutting corners

In life sciences commercial operations, medical, legal and regulatory review governs how fast anything reaches the field. Most attempts to speed it up target the reviewers. That rarely works, because the reviewers are not the problem — the unit of review is.

01The constraint

One claim changes, and the whole asset goes back through review

When an asset is reviewed as a single monolithic artefact, changing one claim re-triggers review of everything around it. A detail aid, an e-mailer and a leave-behind leaflet carrying the same approved claim are each reviewed independently, three times, by the same people.

02The change

Review the component, assemble the asset

Content is decomposed into components — a claim, a data visual, a safety statement — each reviewed once and versioned. Assets are then assembled from pre-approved components, so only genuinely new material enters review. Nothing is approved that was not approved before; it is simply not re-approved unnecessarily.

03What it takes

The technology is the straightforward part

A component taxonomy the medical team actually accepts, a digital asset management system that can hold approval state at component level, and review workflow that understands assembly. The taxonomy agreement is the hard part, and it is an organizational negotiation rather than an engineering task.

04Why it holds

It reduces review volume, not review rigour

This is the reason the change survives contact with a regulator and with the medical team. Nothing about the standard moves. What moves is how many times the same approved sentence is put in front of someone for approval again.

No client is named, no engagement is described and no figures appear here, because none has been approved for publication. What is above is method, and it is stated in full so it can be argued with.

What change looks like

Structural proof, while the outcomes are in approval

These are not engagements. They are the shape of the change each capability makes — stated so that you can judge whether we understand the problem, without either of us pretending a figure exists.

Legacy platform to a system that can change
Illustrative transformation model

Modernization is usually described as a technology move. What actually changes is how long it takes to make a change safely.

Before · The estate today
  • One deployable, released on a quarterly window
  • Business logic duplicated across the application and the database
  • Regression tested manually, so the cost of a change scales with its size
  • Environments that differ from production in ways nobody has written down
After · What it becomes
  • Separable services with owners, deployed independently
  • Logic in one place, with the contract stated and tested
  • Regression automated at the level below the interface
  • Environments produced from the same definition as production

What moved: The constraint moves from the release window to the decision itself. Nothing about the business logic is claimed to improve — what improves is how quickly it can be corrected.

A structural model of the change, not a record of an engagement. No client, figure or timeframe is implied — those publish only against an approved claim.

Conflicting reports to a governed foundation
Illustrative transformation model

Two teams presenting different numbers for the same question is rarely a tooling problem. It is a definitions problem wearing a dashboard.

Before · Where the numbers come from
  • Definitions living inside individual reports
  • Four answers to "how many customers do we have"
  • Access granted per extract, and rarely revoked
  • Lineage reconstructed by asking the person who built it
After · Where they come from afterwards
  • One governed semantic layer the reports read from
  • A definition with an owner, a version and a change history
  • Access evaluated against entitlement, not against a spreadsheet
  • Lineage recorded, so a number can be traced to its source

What moved: Arguments move from whose number is right to what to do about it. That is the precondition for anything analytical, and it is where most AI programs stall.

A structural model of the change, not a record of an engagement. No client, figure or timeframe is implied — those publish only against an approved claim.

Manual handling to a governed workflow
Illustrative transformation model

Automating a process nobody has measured reproduces the existing mess faster. The order below is the part that matters.

Before · How the work runs
  • People re-keying between systems that do not talk
  • Exceptions handled by whoever notices them
  • No record of how long a case actually takes
  • Process knowledge held by three people
After · How it runs afterwards
  • Straight-through handling for the cases that qualify
  • Exceptions routed to a named owner with the context attached
  • Every step timed, so the next bottleneck is visible
  • The process written down in the system that runs it

What moved: Work stops being invisible. The gain is not only the removed keystrokes — it is that the next constraint can be found instead of guessed at.

A structural model of the change, not a record of an engagement. No client, figure or timeframe is implied — those publish only against an approved claim.

Three of six. The others sit on the capability pages they belong to — testing, integration and AI governance — because that is where someone reading about that capability is standing.

The framework

What every case study here will contain

Publishing the structure in advance is a commitment. It means a study cannot quietly omit the baseline, the timeframe or the parts that did not go to plan.

  1. Challenge

    The business problem in the client’s own terms, not ours.

  2. Context

    The environment it happened in: estate, constraints, regulatory position, what had already been tried.

  3. Approach

    How the work was scoped and sequenced, including what we chose not to do.

  4. Solution

    What was actually built or changed.

  5. Technologies

    The platforms and patterns involved, linked to their technology pages.

  6. Outcomes

    Measured results with a timeframe and a baseline. A percentage with neither is not a result.

  7. Next step

    A route to discussing a comparable problem.

The standard

What has to be true before we publish one

  • Written client approval on file before publication, referenced on the record.
  • Every metric carries a timeframe and a baseline, so it can be understood rather than only admired.
  • Anonymized studies are still specific and still true. "A European insurer" is acceptable; an invented company is not.
  • Client names and logos appear only with explicit written permission, and approvals carry an expiry.
  • Legal review before publication, in addition to client approval.

Next step

Bring us the comparable problem

If the constraint described above resembles yours, the useful conversation is about your estate rather than our page. We will tell you what we have done before and what we have not.

Discuss a similar challenge